Course code: WEB-21
Years with company:
Primary programming language:
Other programming languages:
Unit test harnesses:
I have been self-employed for 6 years. I was the architect and lead developer for an in-vehicle infotainment system, for the driver terminals of a forage harvester and of a sugar beet harvester, and for a metal bender. I coach client teams in agile development, agile project management, unit testing, automated builds and tests. My favourite technology is the HMI and application framework Qt.
I am still waiting for a customer who fully embraces testing. One customer explicity forbade me to write tests. Another customer said that with testing it would have taken double the time. I learned to ignore such "requests".
I lived and worked in India, Norway and England - besides Germany, my home country. I am currently living in the South Eastern part of Bavaria - one hour East of Munich. I love hiking in the mountains, which I can see from my office and home.
Test practice now:
I try to cover more than 80% of my code with unit tests. Units are mostly classes, sets of classes, modules, libraries, up to the whole system. GUI test tools like Squish allow to test user interactions and system responses.
I write the tests at the same time as the code: sometimes before the code, sometimes after the code. TDD is my goal, but I don't always achieve it. My TDD steps are sometimes too big. The big steps force me to backtrack and start over with smaller steps in a slightly different direction.
When implementing the CAN communication for harvesters, I wrote a mock object for testing. The mock object can check that an expected sequence of CAN messages occur. It can even answer to requests.
I get nervous, if I have to work on a code base without tests. Then, I start introducing tests, which is onerous in the beginning but pays off in the end.
Embedded systems with an HMI. The Systems run on ARM SoCs with Linux: mostly microprocessors, rarely microcontrollers.
QtCreator, Squish, Valgrind, Gdb, Docker, Yocto, Git, Github, Jira
Under 10 seconds
I like code that is easy to read, understand and change. Such code is helped by lots of tests, which double up as an executable specification.
Function too long:
A function is too long, if it is hard to set up the context in tests or if it is hard to test some execution paths through the function.
Code reviews often take too much time. The fewer tests there are the longer code reviews take. Code reviews trigger discussions that should have taken place when starting the implementation of a story.
Favorite thing about dev:
When people enjoy using my software in real products or when my software makes them more productive, I am happy and a bit proud. This is a fantastic reward for struggling with something as complex as software.
Least favorite thing about dev:
The worst thing is searching bugs for hours or days - just to find out that the fix takes one minute.
I try to use it in my daily development work. I have read your book and Kent Beck's book about TDD.
Why are you attending:
Because reading your book is one thing, working through it in hands-on sessions a totally other thing. It turns passive into active knowledge.