Internal mentoring programme and in-house trainings: it’s time to go deeper
With a growing organisation of almost 35 software engineers specialized in Dynamics 365 Business Central and Dynamics NAV, we face a constant need for learning. We have built a strong mentoring programme, perform solid in-house training and benefit from visiting specialists providing this training. During this time of lockdown these methods need to be spiced up.
We believe that developers need to have a hands-on ‘ah-ha’ experience to make learning stick. So, we sent every developer a common task in a FOB file that they needed to correct using standard Microsoft coding guidelines combined with internal guidelines. The case was, of course, based on a collection of puzzling challenges that one of our senior developers had seen over the years.
“We believe that developers need to have a hands-on ‘ah-ha’ experience to make learning stick. So, we sent every developer a common task in a FOB file that they needed to correct using standard Microsoft coding guidelines combined with internal guidelines.”
– Nicolai Krarup, COO at Global Mediator
Ask them to fix something ‘elaborately’ wrong
Within our training, codeunits had the wrong formatting, wrong variable names, and even the wrong logical structure. This may sound strange but in our case the logic of specific functionality inside the functions was wrong, because the logic of the code-unit’s functionality did not make any sense.
Well versed as they are, a couple of them tried to rewrite everything – which in normal circumstances could have made sense if you do not have any budget restrictions. We insisted on a ‘fix’ to make sure that we could all discuss on a common basis (we do not normally have common tasks) and as this exercise came on top of a normal workload, we tried to mimic real work experience as much as possible.
Bring it back to everyday practicalities
As some of you are aware, a lot of checks are already implemented in the AL development environment (in the CodeCop, PerTenantExtensionCop, AppSourceCop and UICop for Visual Studio Code). In the C/AL development environment for previous versions, we still need to do some formatting and checks manually. Also, we need developers to understand what the impact is of getting it wrong.
As in most of our everyday work with customers (whether on NAV or Business Central), we encouraged the developers to ask for details. To be fair, the team did not use this to fish for solutions but to clarify scope more precisely. Even so, we did not communicate that this first part of their training was to cover what we see as a ‘higher-level’ standard knowledge.
Be specific about learning points
In order to accommodate the more technically minded readers, let us give some specifics about what we have covered in our discussions around the case:
- Do not use nested WITH, or only one WITH on the table level.
- Always use < > symbols with date formula to support localization translation (e.g. CALCDATE(‘<-1Y>’,WORKDATE) will work fine in any language, whereas CALCDATE(‘-1Y’,WORKDATE) will fail if you change language to German).
- If you assign text variable into the text field, use combination of the COPYSTR, MAXSTRLEN functions.
- Rename text constant to describe to any developer what it is doing in that piece of code e.g., use ERROR(YouMustSpecifyItemNoErr,Item.”No.”).
- Put THEN, ELSE and some other statement in the correct place in the code.
- If you want to use REPEAT UNTIL statement, do not use FINDFIRST before, but FINDSET (or, in some specific cases FIND(‘-‘)).
Common standards for many developers on many projects
We work for different customers with different solutions and requirements. We, of course, work on updating our guidelines on Dynamics 365 Business Central and on Dynamics NAV. We run a series of development environments using the latest tools and we have a strong QA department. But sometimes it is still a challenge to bring people together around a common task and learning experience.
The team did well. This first time around took more time to prepare and more time to complete than we expected. So, with an 80% success rate, we will be doing more training like the one described above, and we will use these scenarios as test tasks when interviewing candidates. It will not replace other initiatives we have, but with 2-3 cases like this per year, we hope we can foster more of the teamwork that we are known for and bring people together on a common task.
How do you train engineers that sit ‘together alone’?