40 Tips to help you improve as Dynamics developer

You shouldn’t write code, you are not willing to test #HoskWisdom

I have compiled a list of tips to improve as a Dynamics developer made up of blog posts I have written and blog posts I should have written.

  1. Get certified to broaden Dynamics knowledge –The benefits of Dynamics certifications
  2. Answer forum questions Microsoft Dynamics 365 Community Forums, CRM forum
  3. Know what value to set entity ownership to, Dynamics 365 Entity ownership — How do you decide?
  4. Don’t put code in the plugin class, create separate objects and code properly and unit test.
  5. Understand the activity entity and ActivityParty and ActivityParty Lists
  6. Read blogs daily to stay up to date and keep learning
  7. Automate builds to raise quality, release more often, which reduces errors and boredom — Dynamics 365 and ALM/DevOps Information to get you started
  8. Don’t deploy manually, it’s boring, error prone and you shouldn’t do something you can automate. Dynamics 365 — The cost of manual deployments activities
  9. Master the fundamentals of coding, you will use those skills every day. Start with SOLID Principles.
  10. Use the solution checker to delivering high quality code (not adding to technical debt) — What the solution checker does and why you should use it
  11. Solve own problems by explaining them to a cardboard developer
  12. Understand the business purpose of the solution you are creating
  13. Push back on requirements that need complex customisations
  14. Why Dynamics Developers should always start with the SDK/Web API and learn how it works, rather than google the answer and learn little
  15. Read books for deeper learning and bring fresh ideas to Dynamics development
  16. Not all solutions should be done in Dynamics 365, Just because you have a hammer it doesn’t mean every problem is a nail.
  17. Read the what’s new, depreciated functionality and release guide
  18. Use the XrmToolBox because it saves time and someone has already faced and solved the problem you are wrestling with.
  19. Show users out of the box before getting their requirements and guide them to an out of the box solution
  20. Don’t copy and paste code, it skips the learning phase and can’t adjust your code when the requirements change
  21. Being prepared helps you write better code — The prepared developer writes better code
  22. Avoid taking work home with you, come to work recharged and ready to go — Let go of thoughts, emotions and actions that weigh you down
  23. Team player because IT projects are a team game — Why you need a great team to deliver an IT project
  24. Uses no code solutions before code because it’s easier to maintain and upgrade. To deliver a project on time, stick to out of the box (if you can)
  25. When you write code make it simple, it’s easier to understand, maintain and extend — Simple code is worth the time it takes to create
  26. Write your code, do your job, focus on the details, predict problems
  27. Don’t take shortcuts they create technical debt and you don’t learn anything — No shortcuts to becoming an awesome Dynamics 365 developer
  28. Don’t move job for money, move for role and opportunity. The more you know and the more value you bring, the more you get paid.
  29. Use early binding in your code because it’s easier to understand and it brings the bugs into development not production (e.g. errors found in code, not a plugin running in Dynamics 365)
  30. Uses the plugin profiler to debug as a last resort because you should be writing unit tests which everyone can use over and over. The plugin profiler adds dependencies to solutions and causes solution import problems. It can affect everyone using an environment.
  31. Don’t use the System administrator to test their customisations — The System Administrator role is a benefit and a curse to Dynamics developers
  32. Think in entities
  33. Don’t reuse out of the box fields because it confuses everyone to have a field name and label different. (they also get overwritten when the solution is re-imported)
  34. Organise your solutions to minimise change, speed up deployment and organise the customisations. What’s the best way to organise solutions in Microsoft Dynamics 365
  35. Reflect on what you doing, how you are doing it and how you can do it better. What I learnt in my last role
  36. Write your code, do your job, focus on the details, predict problems
  37. Continuously keep improving
  38. Name your code and customisations so it’s obvious what they do and they don’t need comments. Code should be the one version of the truth, don’t add comments
  39. Think long term and create code you can reuse — Why isn’t code reused in Microsoft Dynamics projects?
  40. Remove code you don’t need, it gets in the way and confuses — The code you take away as important as the code you write
  41. Don’t overestimate your skills and underestimate the task — One simple tip to improve your development and project estimates
  42. Time is a tool, use it to think about the problem when you have time, so you can react quickly when you don’t. 10 books to improve your thinking and decision making

4 thoughts on “40 Tips to help you improve as Dynamics developer

  1. George May 28, 2020 / 2:26 pm

    Greetings Hosk,

    Thanks for the informative post. I am confused on a few tip. Could you provide some clarity?

    > Don’t put code in the plugin class, create separate objects and code properly and unit test.

    What object are you suggesting to use in place of a plugin? Are you saying keep plugins to one class only? How do you recommend unit testing in dynamics?

    > Push back on requirements that need complex customisations

    I’d like to see a post about this. I’m not sure what you mean by complex, and why this should be avoided.

    As a budding developer, some requests seem complex because I’m still learning the system, but after I learn about the “right way”, it’s a cake walk. Are you saying to only do customisations within your circle of competence? What are some example in your experience where pushing back makes sense?

    The following appears to make the previous tip redundant:

    > Don’t overestimate your skills and underestimate the task — One simple tip to improve your development and project estimates

    These sounds the same to me. What is the difference?


    • Hosk May 28, 2020 / 6:40 pm

      Plugin code
      When you put plugin code in a plugin it makes it difficult to unit test because you need to create the plugin context. You should remove the code into seperate classes and methods that you can unit test.

      are developers afraid of creating classes

      find classes

      Push back on complex requirements
      Ideally you want users to use out of the box Dynamics 365, this will bring no maintenance overhead and will upgrade without problems. Any customisation you create has to be maintened and increases the complexity of the overall solution.

      Show users out of the box functionality and get them to try it. The customisations they ask for are not always needed.

      The most complex customisations are code (C#, JavaScript) and this bring the biggest maintenance overhead.

      Try to stick to out of the box
      View at Medium.com

      Don’t overestimate your skills and underestimate the task
      Developers estimates are optimistic and assume everything will go right and they will not be distracted by other activities. Try to use the ideas in the article and see how long similar tasks took. You can often hear a developer saying he is 90% finished and the last 10% takes as long as the first 90%.


  2. Richard Kevin June 3, 2020 / 7:58 am

    Great Blog! This post gives a better idea. Thanks for sharing useful information


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.