Course code: ROL-1
  • Years with company: 1
  • Years programming: 20
  • Primary programming language: C++
  • Other programming languages: C, Python (just a bit)
  • Unit test harnesses: GTest, Catch2
  • Something else: I think I do not fit well (technically not socially) into most large organizations I have been part of so far. I care about (good) deign. I care about unit testing. I care about TDD. I care about clean code. And I know a thing or two about the above (but I still learn a lot each day!) Usually I find very few likeminded collogues, and I find it very energy draining to "swim against the current" in terms of how code should be designed, tested and written and needing to see all the horrible code around me (there are good parts, but generally speaking), feeling helpless to make a change that makes a difference.
  • Test practice now: It depends. If I own it, I TDD. If I don't own it, I try to TDD - but in this codebase, its sometimes actually impossible even to put unit test in place without spending weeks on refactoring.
  • Target system: We code on X11, but deploy on an embedded HW. But I don't know much about the actual embedded system.
  • Dev tools: GCC, CMake, Git, MSVCode CLion/QtCreator, GTest
  • Build time: 1 day or more
  • Coding standard: What standard?
  • Function too long: It fails the SRP test (Single Responsibility Principle) SRP is one of the most misunderstood principals (by those who actually are aware of it) in our industry, and yet one of the most important 3 principals of all.
  • Code reviews: I am trying to move my team to use CRs. Its just in the beginning. I still am trying to make them see the benefits. My team is also open to it, so its on track. The rest do not CR to my knowledge.
  • Code time: 45%
  • Test time: 45%
  • Debug time: 10%
  • Favorite thing about dev: When software is well designed - and it proves its worth. Happens too seldom. I simply enjoy solving problems with software, and I enjoy crafting good software.
  • Least favorite thing about dev: The need to deal with developers who do not care about good software design. That its the only profession where a manager with null knowledge about it can make decisions that that we need to implement and that make no sense.
  • Tdd knowledge: I practice it when ever I can - but there is a lot of room for improvement - I am experienced beginner if you will. I hope to gain more technics and improve my overall TDD skills in this workshop.
  • Why are you attending: I was one of the people who pushed for it. This organization (like most unfortunately) is filled with many good people, that know sh*** about how to write good software. And I will take every opportunity to get better at TDD.
  • Back