Course code: AS-2
  • Years with company: 1
  • Years programming: 16
  • Primary programming language: C#
  • Other programming languages: C++,C,JavaScript,Python,SQl
  • Unit test harnesses: MSTest, Google Test, MoQ (mocking framework in C#)
  • Something else: 1) I am a smartass. I was a computer science lecturer for a year (Datbases,Design Patterns,C++) , I enjoy complex challenges and I like understanding the 'why' of almost anything I use. I did a bachelor's degree in (technical) computer science in 2008, taught at the same place in 2019-2020. Was very happy to help introduce the concept of unit-testing. in 2019 I worked with some PhD students and helped make their code more testable/reproducable/documented,and porting Matlab code into C/C++. I prefer to adhere to the unix philosophy, small simple programs, well tested, functional (no side effects and deterministic) whenever possible which means properly structuring code. Out of my 13.5 year career so far, 11 were in C# and 2.5 in C/C++. I shifted to C++ because C# was not sufficiently challenging anymore and too much focus is on 'simple' administrative systems in most C# heavyweight companies.
  • Test practice now: I only did a little embedded here so far, there was no unit-testing, no regression tests, no gated checkin, no stubbing, mocking.. TDD.. forgive me for I know how I have sinned.
  • Target system: Oof. I only did a bit of embedded. ATmega128, we don't really care about 'performance' that much, so careful thought into tailored code is often not an issue. Energy efficiency is not an issue, stack-size might be.
  • Dev tools: I wish I could use e.g. valgrind.. GCC debug.. I like IDE's like CLion, but we often resort to Atmel studio and are bound to Windows ¯\_(ツ)_/¯ Visual Studio is still my favorite though.
  • Build time: 30-60 minutes
  • Coding standard: I don't know what coding standard we use when developing C/C++ for ATMega. I just 'follow' along as best I can to keep the codebase consistent, and deviate intentionally towards best-practices and standards-compliance.
  • Function too long: Theory: Cyclo > 3, unless there is a good reason. MI4-index is below 80%. Reality: spend 1+ hr understanding. My ideal: unit-testing becomes complex or unfeasible; code coverage remains low.
  • Code reviews: We check the style, but the code reviews usually happen 'after' a rather big chunk of work is done. We could be more agile, do not employ scrum. Code reviews are more of a feedback/suggestion oftentimes.
  • Code time: 20
  • Test time: 10
  • Debug time: 70
  • Favorite thing about dev: Everything, especially understanding why something is not working properly. Also the knowledge of making something that can only be as good as I can make it; minimizing complexity while maximizing performance while maximizing maintainability.
  • Least favorite thing about dev: Maintaining code I don't understand. Often, I don't understand a function until I see it's unit-test. Lacking unit-test I must know all possible ways it can be called, recursively for all heuristic paths, which is improbable. It is scary.
  • Tdd knowledge: A lot, I think. I followed an extensive course 10 years ago. I have worked with pure TDD driven development/scrum and gated checkin for years. Within my current department, in C/C++ TDD is currently improbable by merit of lacking design.
  • Why are you attending: 1: Was automatically added 2: I want to know how to do embedded mocking and stubbing and ask annoying questions such as "James, how would you deal with non-deterministic functions?, would you do unit-tests with random-data? or mutation tests?, UB?"
  • Back