Tag Archives: Msdn

Taking on New Challenges: Joining the IE Team

How I Started

I’ve been into computers since I was a kid. The story is long, but I essentially started writing software in the 5th grade at North Elementary School in East Liverpool, Ohio. We had a quick introduction to computers. Our teacher discussed high-level and low-level languages and then introduced us to BASIC programming. I wrote my first program:

10PRINT “TOBY”
20GOTO 10
RUN

(Aside: For those that don’t know, I begrudgingly admit I went by “Toby” back in those days).

800xl[1]My eyes filled with wonder as my name scrolled down the screen. I immediately looked at the next instructions, and the next, and the next, and the next. My dad picked up an ATARI 800XL for the house. I spent many a full day at home working on that computer — painstakingly putting Microsoft ATARI BASIC and ATARI Assembler instructions from programming books and watching with wonder as the screen flashed exactly what I told it to do and the four voice, 3.5 octave sound screamed at me. I’ll spare you the details, but those were the beginnings of my fascination with computers. Some years later I had, for a number of reasons, stopped programming on the ATARI. When it was time to go to college, my parents got me a Packard Bell 486 DX2 66 computer. I went to college for Graphic Design – not computer science. However, when I found BASIC on the computer, I suddenly found myself hanging out with the C.S. folks more than my own classmates.

The Wonder of the Web

packardbell[1]After three semesters of college, I ran out of cash and my choice of Graphic Design over computer science made it hard for me to want to go back to college. I moved to Greenville, SC in 1994 and started playing with my Packard Bell. I mostly used it to talk on BBS’s and occasionally AOL when I could afford the time (for those of you that don’t know/remember back that far, you used to get charged by the minute for AOL use). I spent a bit of time writing small desktop applications with my copy of Visual Basic 3, patching software to get it to do what I wanted, or adding photos of myself inside my favorite games to my friends amazement. But I also started playing with HTML – something that had not yet standardized, but that I wanted to be a part of. I’ll never forget my first webpage. It had a picture of Alicia Silverstone on it – the “chick from that Aerosmith video”. The thing I liked about the web is that it combined my love for graphic design with my need for technical understanding.

I’ll again spare you the details and skip forward a few years. I was working for a consulting company called Metro Information Services as a contractor for AIMCO – at the time it was the largest property management REIT in the country. I worked on several web-based intranet applications in the 1999-2000 timeframe getting use something new called XML Data Islands, DHTML behaviors and something new called XMLHttpRequest. This allowed me to create applications that appeared more responsive and did work behind the scenes on users behalf. I fell in love with this technology with Internet Explorer and probably overused it. With just HTML and JavaScript, I felt back then that eventually most applications would become web-based with very little need for ActiveX or Java fillers. I knew that the server was still an important part too so I continued to work on enterprise middleware and database development. But I knew that the web – both server and client — was where I was meant to work.

Moving to Microsoft

Skipping forward to 2006, I had worked contract after contract, making a lot of money but starting to get bored and burned out. I was going to take a year off work and “play” with the technologies I loved most. Then Microsoft called. They had an opportunity to work with the teams that built ASP.NET and IIS. This seemed like the best opportunity so I took it. I joined as a Programming Writer for IIS. You could summarize this as simply a “documentation writer” position if you didn’t know any better. That said, I came to realize that this job required skills as both a great communicator and a great programmer. You needed to learn how to analyze API code that was written, and describe how to use it without any help. I loved my job when I first started it. However, the continued pressure to document every exposed method no matter how trivial it was also began to weigh heavily on me. I loved the web and this position seemed like the perfect position for me – till you find yourself writing documentation such as “The IAppHostSectionDefinition::Name Property Gets the name of the current configuration section definition.”

loginI had a growing desire to fix MSDN. As a developer, there were so many things that I felt I could help MSDN with, I thought I couldn’t go wrong. I loved working with the MSDN and TechNet teams. I helped redesign the home page based off of customer feedback, metrics we collected and the overall direction the company was heading. I started the MSDN News program which allowed us to aggregate content from various places inside and outside of the company and disseminate it across multiple locations. I designed and MSDN Insiders program. At every turn, however, I just felt like I was building someone else’s vision rather than making the impact I wanted to. I also, strangely enough, wasn’t getting to use the latest, greatest technology to build MSDN. I had a heavy desire to build HTML5 sites, mobile sites, and incorporate features like pinning. It’s not that I didn’t believe in what was being built, but my passions for it were not there.

Introduction to IE

UntitledI started diving into HTML5, CSS and JavaScript pretty heavily again. Inspired by the type of work that Rey Bango was doing, I wanted to reestablish my passion for the web. I began talking to people about this passion and paying more attention to what the community was saying about standards, development challenges, and of course, browsers. As I read more books I noticed that IE was rarely mentioned and if it was, it was in a bad light. Some of this was perception but some of it was reputation earned long-ago on the backs of still-lingering down-level versions of the product. I became angry when I saw a cartoon being passed around twitter. The cartoon, which many of you may have seen, was of three boys dressed in browser costumes. A Chrome-costumed boy had a Firefox-costumed boy in a headlock and they were clearly battling it out – each shouting the name of their product while holding a determined look on their face. In the corner was a baby-blue pajamad boy with a baby-blue helmet on. The helmet, of course, had an “e” on it to indicate Internet Explorer. This boy wasn’t battling at all. He was eating paste! This made me mad because I knew that the IE team was actually listening for feedback and had made considerable investment in battling back since IE6. I knew we still had our problems in IE, but certainly they didn’t deserve the “touched boy eating paste” image.

I sent a well-thought out email to the VP of IE and expressed my frustration with not only the cartoon, but the idea that we weren’t even considered a player for many people. I expected to get a pink slip for this “career-limiting email”. How often have you heard about someone telling a VP that their product needed work to be rewarded for it? Not often, in my experience. However, I was surprised to see an email come back from the VP fairly quickly. At the end of my email I asked “what can we, as employees, do to help with these problems?” The answer for this VP was pretty simple – “come and fix it.” At the VP’s request, I met with a man from IE. He listened to me and what I was passionate about and what I felt needed fixed. He asked me if I had worked with HTML5 canvas yet to which I told him I did not. He asked me to go play with it for a couple weeks or a month and let me know if I liked it and what I thought about working with it for a while. I wrote a few quick[1] demos[2] in a few days with HTML5 and shot them over to him. They weren’t great so I expected him to hate them. I hadn’t optimized my code. I wasn’t using standards. I wasn’t doing all the things someone interested in performance should do.

darkbookWe met again for coffee and he listed some of these things on the board as we chatted. At the end of the conversation he said “these could be your commitments.” Long story short, after a few more discussions I was given an offer to come join the IE performance team. I’ve got my work cut out for me. The people I met with in IE are top notch guys. They know their stuff inside and out. They know not only the code base and how it works, but how it should work. I’m told it’s going to take me about a year just to ramp up and be slightly effective. These guys have been working on the product for several years on average. I’m humbled to be able to work with them. I doubt I’ll ever be as smart as them, but I’m hoping to make my small impact on the product.

I was thankful to work with amazing people in MSDN. I’m thankful for this opportunity to work with great people again in IE. I’m excited about this move and the work ahead – something I desperately need to feel again about the work that I do. I’m excited about not only making IE better, but making the web better along the way for all of us.

My Request to Each of You

I’m going to be looking for feedback on IE. I don’t mind brutally honest feedback. If you’ve got it, I can take it. I really don’t know what work will look like in IE entirely or exactly what I’ll be able to do with most of the feedback – particularly so soon after joining the team. However, I’ll always be looking for feedback and will do my best to feed that back into the appropriate people inside the team.

Thanks for indulging me as I reminisced.

[Update] Just for clarity sake, I’m not sure how transparent I can be about what I’m doing or what the team is doing. You’ll never hear a new announcement about features or release dates or anything else coming from this blog. That’s really up to the team to communicate on official blogs. Just want to set expectations correctly.

What’s wrong with MSDN documentation?

A large part of my job at Microsoft is to provide developers with the knowledge they need to make use of the IIS 7.0 SDK.  While the information about IIS 7.0 is not out yet for review, there are plenty of docs provided in other areas, such as the .NET Framework SDK and ASP.NET sections, which can be used as a benchmark.   In order to make the IIS 7.0 SDK a success, we must do more than just put out a good product. We must also describe how to use it properly or it just will not be used.  So I pose a question to anyone who has ever looked something up in MSDN, what is wrong with the documentation you have used so far?  What is good about it?  What would you like to see to a greater/lesser extent in our documentation?   Feel free to flame us, or praise us.  If you have suggestions, comments, or ideas, feel free to express them here.

Your feedback will help me understand how to increase your satisfaction with MSDN and Microsoft in general.

Or better yet, if you have some desire to play with new technology that isn’t documented yet and provide that content to a worldwide audience, why not apply