Course code: WEB-17
  • Years with company: 2
  • Years programming: 15 (10 professionally)
  • Primary programming language: C historically, C++ the past 2 years
  • Other programming languages: Lua, Groovy, Python, Bash scripting, many build system languages
  • Unit test harnesses: Cmocka, Doctest
  • Something else: I work as a gardener at the Japanese Tea Garden in SF once a week. More than a programmer, I identify as a writer. I have a dog, and I try to walk 5+ miles a day with her. I cook a lot of food - lots of Thai, Vietnamese, French, Chinese (I'm *really* excited about my brand new German fermentation crock).
  • Test practice now: Unit testing (written after the fact), manual integration testing, automated integration testing (usually controlled by a test sequence which talks to to the target hardware)
  • Target system: Target code: variety of ARM/PIC/AVR systems, 8-bit to 64-bit, usually no OS. I also frequently program for POSIX systems
  • Dev tools: gcc/clang, clang-format, lizard, GitNStats, Jenkins, meson, ninja, gdb, openocd
  • Build time: 31-60 seconds
  • Coding standard: I am currently developing my own standard. I reference Barr's standard, as well as the C++ core guidelines. Code is auto-formatted to eliminate formatting debates.
  • Function too long: CCC Metrics (collected by Jenkins for each build), Intuition (can I grok it all in one flow?), inconsistent resolution (are some function calls high-level, while others are groups of lower-level calls?)
  • Code reviews: I am the only developer, so I use self-review checklists. When on a team: all changes reviewed by 1-2 other programmers. I encourage clients to have the team define a review process & review criteria.
  • Code time: 25%
  • Test time: 35%
  • Debug time: 40%
  • Favorite thing about dev: I am a creative person, and coding is a great way to express that. I love embedded software in particular because it is more concrete - my code works on real hardware and does something in physical space.
  • Least favorite thing about dev: Poor quality everywhere, and seeming lack of concern over it. Teams complain they "don't have time" to do it any better. Teams responding to my suggested improvements with "we know we should be doing that", yet they never adjust.
  • Tdd knowledge: I am quite ignorant. Write the test before any code. Small incremental changes.
  • Why are you attending: If I want to preach quality, I must practice the techniques myself and insure they are incorporated into our development processes. We can only teach and influence by example, never exhortation.
  • Back