Course code: MEG-1
  • Years with company: 6
  • Years programming: 20
  • Primary programming language: C#
  • Other programming languages: C, Java, Python, Shell
  • Unit test harnesses: Ceedling (CUnit), NUnit, JUnit, Google test
  • Something else: I enjoy being active (hiking, running, golf), (re)learning to play guitar and travelling
  • Test practice now: Currently NUnit and Ceedling (CUnit). Write failing test, write code behind the test, make the test pass, commit, refactor a bit where necessary. (I could use more discipline on the refactoring bit).
  • Target system: It's kind of a typical pre-web embedded system comprised of a microcontroller for data acquisition (embedded C) communicating to a single board computer running a Windows C# application via a CAN bus.
  • Dev tools: For the embedded bit, use Atmel studio (now MPLAB X), but found that CLion is a more navigable IDE (refactoring tools inclusive). For the C# side it's Visual Studio with the Resharper plugin (for unit testing and refactoring/autocomplete tools).
  • Build time: 31-60 seconds
  • Coding standard: We don't really have a coding standard. Part of this was practicality based as products were accreted from acquisitions - not practical to rewrite large aspects according to coding standard. My efforts are for smaller/testable sprout features
  • Function too long: When a function seems to do more than one thing, it's too long. When it handles multiple product variants as well as other things, it's too long.
  • Code reviews: We don't currently do any code reviews. At best in Valley Forge, it is one developer per product/product line. Would like to start - emphasis on readability/testability over style.
  • Code time: 15
  • Test time: 30
  • Debug time: 55
  • Favorite thing about dev: I like that ideas and pure math are the 'materials' to characterize the world around us, as well as the process of trying to adopt sound (read economical and succinct/correct) engineering practices.
  • Least favorite thing about dev: It's hard to clean up and 'pay' (via code rework) for messes by quick-fixes made in the past. I try to look at it as more of an opportunity to look for ways to not predict the shape of the code beforehand, but make it easy to work with when needed.
  • Tdd knowledge: I know that Kent Beck wrote a TDD framework for Smalltalk in the mid-90s. The practice makes sense and gives me (and the business) more confidence that something will work, and shortens the time to resolve what bugs do crop up.
  • Why are you attending: I've been doing TDD for about 15 years, but I want to make sure I am doing it properly, and learn more techniques (test-wise and design-wise) to build up a catalog of strategies to use for new designs so I don't burden the business with risk/cost.
  • Back