Course code: WEB-35

Years with company: 16

Years programming: 20

Primary programming language: C++

Other programming languages: Python Infrequent: java, c#, ruby, javascript, ...

Unit test harnesses: Many including CppUTest googletest, boost, assert, unittest.py junit, nUnit, custom, ...

Something else: I like the challenge of getting unit tests working in legacy code. I'm humbled that more programmers don't currently do TDD.

Test practice now: Combination of class-level unit tests, automated integration tests and system tests, plus manual exploratory manual testing.

Target system: Arduino, embedded linux, embedded Windows, desktop exercises.

Dev tools: Mix: Macbook, Eclipse, AtmelStudio, Aduino IDE, TextMate, Visual Studio

Build time: 31-60 seconds

Coding standard: varies by project. Usually minimally specified and syntax vs semantics/design. Rarely "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" by Herb Sutter et al

Function too long: When it's hard to quickly understand or could be clearer if refactored. Could be as little as a one-line wrapper with a good intent-revealing name. Probably no bigger than one screen full.

Code reviews: varies by project, from zero to by weekly to pairing

Code time: 10

Test time: 40

Debug time: 50

Favorite thing about dev: Quick tangible progress. Quick feedback. What software enables in the world.

Least favorite thing about dev: Feeling on not fully understanding things. Risk of small mistakes having big consequences. The common perception that programmers are already doing the best they can using limited approaches.

Tdd knowledge: I've studied and practice TDD. I use it on my projects. I use it on client projects when possible. It's common that I'll demo some examples in a code base but that the teams will not take it and run. Reasons cited include: no time, too hard, fragile.

Why are you attending: To grow more fluency with TDD for embedded. To grow techniques. To learn ways to explain and motivate the use of TDD.