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.