Course code: WEB-29
  • Years with company: 4
  • Years programming: 20
  • Primary programming language: C++
  • Other programming languages: C, XC (for XMOS), Python, bash, Groovy
  • Unit test harnesses: Googletest
  • Something else: Probably the thing about me most pertinent to this training is that I largely work with what Michael Feathers refers to as a large legacy codebase.
  • Test practice now: There are a number of ways and it varies. New code is generally developed along with unit tests - these run as part of the build on the CI system. The unit tests either run the code natively on Windows/macOS or use a simulator for hardware specific functionality. There is an automated test harness using real hardware for end-to-end/integration tests. We have some great QA engineers who do manual testing and who develop automated tests. I do some manual testing while developing the code. I work with a legacy codebase and some of these testing methods have been relatively recently adopted - a lot of code is not under test...
  • Target system: USB, XMOS processor, audio, real-time.
  • Dev tools: VSCode, git, XMOS toolchain (including XGDB), xTag debugger, GoogleTest, lots of bash, Beagle USB analyser, Jenkins, Artifactory, YouTrack, make, cmake
  • Build time: 31-60 seconds
  • Coding standard: We're currently discussing coding standard across the company - there isn't one currently in place.
  • Function too long: I feel like I could look this up and give you a technically correct answer. In practice, a function is too long when I can't keep all the context in my head, or when it does more than one thing, or maybe more than 50 lines. It varies.
  • Code reviews: Code reviews vary from meetings to discuss the approach taken to fix a particular issue to using UpSource or using merge requests in GitLab. They vary from project to project and the availability of appropriate reviewers.
  • Code time: 20%
  • Test time: 20%
  • Debug time: 50%
  • Favorite thing about dev: Building things, getting things done, problem solving, helping people.
  • Least favorite thing about dev: Feeling there is not enough time / resourcing.
  • Tdd knowledge: I have heard about it on podcasts, I have read a couple of books, I used it in a project (which went well) and I enjoyed the rhythm of TDD.
  • Why are you attending: I first heard you (James Grenning) on the Embedded.fm podcast, I have your book, I have used TDD before (it went well and I would like to use it again) and I want to learn how to use TDD more effectively. It should also help management buy-in.