Course code: WEB-31
  • Years with company: 0
  • Years programming: 14
  • Primary programming language: C
  • Other programming languages: C++ Python Rust C# Java
  • Unit test harnesses: CppUnit Google Test ROS
  • Something else: I want to become an expert in embedded safety and reliability. I want to have a sound understanding of how development practices affect safety/reliability outcomes. I also wish to become a part of the growing embedded Rust community, and learn how the language can be used as a tool for functional safety in complex embedded systems.
  • Test practice now: Unit testing. On my (Agile) team, adding tests for all new code was encouraged but not required by policy, and there was a large legacy codebase without coverage, so we didn't see the full benefit of testing. Tests were run every commit by CI but not automatically on a dev workstation. I learned about TDD but never got the chance to put it into practice.
  • Target system: Previously I have targeted STM32 as well as other ARM platforms, either on top of Linux, RTOS, or bare-metal.
  • Dev tools: I'm most comfortable in vim but I can usually tune an IDE enough to be happy, when needed. I usually use a GCC or clang toolchain.
  • Build time: 31-60 seconds
  • Coding standard: We based our C++ standard on Google's, focusing more on code style consistency than higher-level issues.
  • Function too long: - Whenever it's not obvious how to isolate for testing. - Whenever it feels like it does more than one logical "thing" (I guess this is subjective). - Whenever I have to start counting arguments in the signature to call it.
  • Code reviews: Organized with GitLab using Merge Requests. Reviews required two approvals from team members as well as a successful CI build/test.
  • Code time: 40%
  • Test time: 30%
  • Debug time: 30%
  • Favorite thing about dev: Problem solving, architecting, implementing new things. Making hardware do things! Sometimes I like debugging, especially when the problem is interesting without being too frustrating.
  • Least favorite thing about dev: Most of the time I hate debugging. I initially hated writing tests but I've come to enjoy the way they force me to reexamine my code structure -- otherwise I tend to go down an implementation rabbit hole and end up wasting effort.
  • Tdd knowledge: I have read TDD for Embedded C, though it was a few years ago. I read Kent Beck's book years earlier, and I found it useful, but I couldn't quite grok how to apply it to the embedded work I was doing at the time until I read yours.
  • Why are you attending: My work signed me up for it! But I'm excited about it because since learning about TDD I've wanted to put it into practice, but haven't been able to get team adoption. Jumping in with a whole team and learning from an expert is the way to go!
  • Back