Course code: WEB-33
  • Years with company: 1
  • Years programming: 19
  • Primary programming language: C
  • Other programming languages: C#, Python
  • Unit test harnesses: Unity
  • Something else: I am a big fan of Embbedded FM, which is how I know of you. When visiting California I met Elicia for stickers :)
  • Test practice now: Unit testing with Unity/FFF. Tests are generally written after the code. Tests are built into our CI pipeline to be run on commits. We also have Hardware In the Loop testing for integration level testing
  • Target system: STM32L5 M33 based hardware; bare metal finite state machine based application; GCC/CMake toolchain; The product is a micro linked to a custom ASIC radio chip over SPI
  • Dev tools: GCC, CMake, CLion, Azure DevOps
  • Build time: Under 10 seconds
  • Coding standard: Err, I don't know which standard it is similar to, but we do have a pretty tight spec. We have markdown doc in our /doc folder in the repo with the rules. Sometimes it is a bit arbitrary, but on the whole I like it and it seems good for quality
  • Function too long: A feeling. No static analysis tools, or even rules of thumb. Not ideal.
  • Code reviews: We generally work in feature/bugfix branches, and then do PRs in master branch. The PRs need to be reviewed by the 2 other firmware engineers in the team. The obvious weakness to me is the lack of focus on "how good are these tests" in the review.
  • Code time: 4
  • Test time: 2.5
  • Debug time: 3.5
  • Favorite thing about dev: Simply, building code that does interesting things. I love building a product to do a specific task, and hopefully creating a good design, and bug free implementation.
  • Least favorite thing about dev: Not always understanding the entire system, and having unexpected factors cause problems. Also, having to be very pedantic about small issues in reviews.
  • Tdd knowledge: I think a reasonable amount. However...! I really want to know how to fit it into what sometimes feels like R&D - how can I write tests before code when I don't know what I'm doing yet, or how I will achieve something? Flexible process?
  • Why are you attending: I want to move my team to a point where we are confident about what we are delivering. We are making a module that may never get remote bug fixes, so we need to be very sure about the code we write. I believe you have some great insights into this.