C++ AMP: The Test Team - Hallway Office Tour

Play C++ AMP: The Test Team - Hallway Office Tour
Sign in to queue


C++ AMP (Accelerated Massive Parallelism) is a small set of open specification language extensions (two of them) and a single library (amp.h) that makes general purpose GPU programming (aka GPGPU) a first class, seamless experience in modern C++.

You've been able to experiment with C++ AMP since the VS11 Developer Preview back in September 2011. We figured it was a good time to go C9 on the C++ AMP team. So, we did. Four interviews have been conducted that pretty thoroughly cover C++ AMP and the people who design, implement, and test it. C++ AMP is a great technology for native developers seeking to harness the power of the GPU using the language and tools they are already comfortable with. C++ AMP is also an open specification and we'll see other compiler vendors producing C++ AMP implementations for their target platforms soon—that's been the goal since Day 1.

Get VC++11 Beta Now - test out AMP!

Here, we meet the members of the C++ AMP test team;  the engineers who write C++ AMP test cases to push the technology to its limits, ensure that features work as intended, find bugs, make sure the technology is ready for prime time before it gets in your hands.

In Old School C9 fashion, we start off in an office - of team leader Jerry Higgins in this case - and then walk around the building to meet the C++ AMP  test team members in their native habitat (offices).

Meet Jerry Higgins, Joe Mayo, Bharath Mysore Nanjundappa, Pavan Marella, Kevin Gao, Lukasz Mendakiewicz, Daniel Griffing, Hasibur Rahman, Pooja Nagpal, and Tamer Afify. Come take a hallway tour with us.


See Part 1 - Daniel Moth: AMP Overview
See Part 2 - Yossi Levanoni: AMP Architecture and Design
See Part 3 - The AMP Development Team Roundtable



Download this episode

The Discussion

  • User profile image

    Hi Charles,

    Very interesting video, thanks!

    But I don't understand "Software Engineer in Test" phenomenon in general. I mean, if you're a decent engineer, why should you be writing _only_ the testing code for things which were produced by other developers?
    I'd understood if the production of testing code were (maybe boring) part of that same developers who authored the original product. But here, I can see engineers are _only_ writing tests, and this continues years...
    Some insight from these guys would be great. Do they enjoy this?


  • User profile image

    Hi Zura,

    The Software Engineer in Test career is only boring if you want it to be - and lots of really senior developers at Microsoft have at one point or another been an SET.

    It's a bit like a battle of wills between the SETs and the normal devs; the dev writes some new code, and the job of the SET is to prove himself by finding the bugs in the code. The job of the dev is to not write the bugs in the first place. As the developers get better at not writing bugs, the SET must get better and more ingenious at finding the bugs in the first place.

    If you think about it, SETs have arguably a much more fun job than devs. They don't need to spend their life thinking about customers or features or compatability and upgrade paths and bashing out more code to comply with EU law. All they need to do is look at the code that someone else wrote, beat it with a stick and send back the mangled remains to the original developer with a note saying "I bashed it with a stick and it broke. Please fix".

  • User profile image

    Charles, I stumbled on this video:
    lecture sounds cool, but audio is terrible. Do you think it would be possible for you to follow MS employees with a cam if they are giving some cool lecture like the one on the link.

  • User profile image


    I see. Thanks for the insight. Doesn't sound boring anymore, especially when the path of converting to the regular SDE exists.

  • User profile image

    Hi Zura,

    There are many dimensions to a Software Design Engineer in Test (SDET) role at Microsoft, but the most important dimension is development/technical skills.  When you test a programming language, you write code. You write code that exercises the grammar, code with targeted imperfections to assess error detection by the compiler front-end, back-end or linker, you may create code generators, modeling tools, transformers that morph code from an abstract syntax tree, workloads, samples or stress situations that push the technology to its limits. This is not the only thing that an SDET does. Influencing the design through design discussions, feedback on usability and issues found through thought experiments and proof of concept designs are an important part of the job. Testing parallel libraries, language constructs and code generation is more than a little challenging and can only be done through writing code that is often pretty interesting. There are other parts of the job that vary considerably depending on the technology you are working on, but writing code is a major part of the SDET role.

    I know many excellent SDETs that are far beyond decent as engineers.

    Changing your role from SDET to SDE or Program Management (PM) is possible, as is making a role change from PM or SDE to SDET. Which of these roles best suites a particular engineer is a matter of personal preference and/or proclivity.

    Hope this helps answer your question.

    Best Regards,

    Jerry Higgins

  • User profile image

    Hi Jerry,

    Thank you for the very informative reply. That definitely answers my question.


Add Your 2 Cents