This is an unredacted brain dump of findings from our various customer projects and interactions. All of these findings are fed back into our process, so you might find them scattered all over our wiki in the corresponding places.

1. Meetings
2. Mentoring (weekly one-on-ones with a fixed date)
3. Small Issues
4. Documentation of processes

1. Ideally, editors rotate through so that everyone gets an insight into each project
2. Alternatively, define responsibilities and deputies (“pair programming”)

1. To prepare the work packages
2. As a kick-off for implementation
3. More time in advance pays off
4. Communication serves as a review and for knowledge transfer

1. Regular event is good!
2. Mutual sanity check

   1. Use (inter) actively
   2. Also use as a design review (concepts), not just as a code review
3. No compulsory course!
4. Better planning!

   1. As a presenter: “What do I want to convey or get?”
   2. As a participant: “What do I want to take with me?”
5. Brief description on Slack or in invite so that colleagues can decide whether they want to participate
6. Set level of detail so that all participants can follow

   1. If too detailed, EVERYONE is allowed to ask for less details

1. MS Teams, Slack etc are good for synchronization (“event-based”), not for documentation
2. Issues are perfect for thematic and asynchronous discussions

1. Markdown in repo for software and source code documentation
2. Dokuwiki for project and user documentation

   1. PlantUML == good!

1. Asynchronous communication about issues works well
2. Update description when details change
3. Use comments

1. DQMH
2. State machines
3. Modularization
4. Generate more reusable code

   1. FPGA!
5. Start the design with the hardware
6. Resilience: Take error handling into account when designing new features

   1. Check the API/interfaces of functions programmatically
   2. Match cluster elements to DB fields
   3. Throw errors for any mismatches!

1. Debug-Driven Design: Have debug information ready right from the start
2. Implement one feature (and only the feature) at a time

   1. Focus: Only edit the feature / bug that I'm working on
3. Pair programming / pair debugging

1. A feature only works if the function has been proven (not if no error pops up)
2. Structured approach

   1. Think first and isolate errors, document
   2. Always start on the left: Search for and at the source (origin), not where the symptom becomes visible
3. Different approaches

   1. Hardware: Only test I / O or communication, not together with algorithms
   2. Algorithms: modularize code and test it separately
4. Reduce to minimal examples as early as possible instead of always testing the entire code

   1. Method of looking closely vs. systematically collecting data
5. Define test scopes (“divide and conquer”)

   1. What should be tested in detail (especially signals, new trades)
   2. What will be tested in large
6. Before calling in colleagues: think and document !!
7. Special case FPGA

   1. Minimal examples for small / quick compilations
   2. Provide parameter sanity checks on the FPGA for everything that works

      1. Draft checks together with design
      2. Does the API get meaningful values?
8. before trying to fix a VI / typedef for hours, try to recreate it from scratch.

1. Error documentation: Which errors have occurred? Maintain at least a “private” log
2. If it took more than a day to find a bug: Document what led to it
3. Maintain error code list
4. Disposable test branches are allowed to be able to use the advantages of git while trying something out