Course code: WEB-23
  • Years with company: 0.5
  • Years programming: 25
  • Primary programming language: C
  • Other programming languages: C++ Java
  • Unit test harnesses: Gtest XUnit Junit
  • Something else: I have been a mainframe programmer for a long time before my current job, so I'm used to working with a tool chain that is a couple of decades less "modern" than what most developers are used to. I'm also used to having to spend a substantial amount of time, making very different systems talk to each other.
  • Test practice now: When working from a spec, often there is an official test vector set that can be used for validation. Sometimes there is an alternative implementation for a different piece of hardware that can be used for reference. If neither is the case,
  • Target system: Various hardware security modules (HSM's) programmed in C or C++. We develop code in MSVS, but each target has its own proprietary C compiler, usually building in a Linux Docker image. Compiled binaries are then hand-loaded onto the target platform.
  • Dev tools: MSVS IntelliJ
  • Build time: 1-5 minutes
  • Coding standard: We have internal coding standard that focuses on correctness and security of our software. I have been part of organizations that spent a lot of time on natural language, but in my opinion that has mostly been a waste, so I much prefer readable code.
  • Function too long: When I can't see the whole thing in a standard text window, or when the list of parameters contains multiple optionals controlling multiple code paths inside the function.
  • Code reviews: In my opinion, code review is more about sharing knowledge than anything else. You can have great discussions about architecture and style, but it is uncommon for bugs to be found in the review process.
  • Code time: 30
  • Test time: 50
  • Debug time: 20
  • Favorite thing about dev: I like the art of imagining something inside my mind, and eventually prove it is logically consistent.
  • Least favorite thing about dev: I dislike working overtime trying to finish multiple projects with the same deadline. Especially when there is never time to consolidate/refactor an old codebase, but always time patch systems that have not been properly maintained.
  • Tdd knowledge: My experience has been that it works great when using the most modern/mainstream toolchains. When using older tools, it's much more of a chore, and so requires much more discipline to do.
  • Why are you attending: I'm new to the team, and some of the other team members have recommended the class. Also, some of the coding standards and development processes adopted by the team are inspired by the course - so it makes sence for me to adopt as well.