Course code: JHAP-1
  • Years with company: 5
  • Years programming: 9
  • Primary programming language: C
  • Other programming languages: C++, Python, Rust
  • Unit test harnesses: Unity, GTest, Catch2, Doctest
  • Something else: I have two rescue dogs: a puggle and a lab mix.
  • Test practice now: Using a combination of CMake and CTest (usually with Catch2) or using ceedling with Unity and FFF
  • Target system: ARM Cortex-M microcontroller
  • Dev tools: vim, IAR, cmake, gcc, clang, VS Code
  • Build time: Under 10 seconds
  • Coding standard: Our company (for C) uses an adapted Barr Group coding standard. For C++ I tend to use LLVM's style guides and try to follow the ISO CPP Core Guidelines elsewhere.
  • Function too long: When it takes up more than one page in vim.
  • Code reviews: Different projects use different solutions. Embedded work tends to be using Collaborator, but other projects have used Crucible since it *can* integrate well with JIRA (though often not that well in practice).
  • Code time: 20
  • Test time: 20
  • Debug time: 60
  • Favorite thing about dev: I like solving complex problems. For embedded specifically, I like that it has a real, physical impact outside of the computer.
  • Least favorite thing about dev: All the paper cuts and difficulties that come with writing software that works well and consistently. It's exhausting having to go through 20 searches and try 8 different solutions before finding the vaguely documented solution for your problem.
  • Tdd knowledge: I know that it is a methodology that revolves around writing the test code first, then writing the implementation to satisfy the tests. Strict TDD would require writing test code that fails first, then fix it as simply as possible.
  • Why are you attending: I want to improve the software quality of our organization. I've tried using TDD on previous embedded projects but the time required to look up how to do things in C and adapt build systems meant I couldn't do much due to time constraints.
  • Back