From List

Second year software developer anniversary

I’ve officially been a Microsoft Dynamics Ax developer for 2 years! :-)

All and all it’s been a good development year. I’ve had the opportunity to go to two clients on-site, I attended the Development 3 training and a workshop at Microsoft.
With the support of seniors and management, I have come a long way with Dynamics AX in the last two years. At the same time, if you believe Peter Norvig, I have at least 8 more years to truly become a developer!

Last year I was extremely enthusiastic about my Dynaniversary and posted a celebratory post exactly on the 1st of March. I also wrote a second post two days later detailing my goals for the year. While this anniversary post may be 31 days late, I figured since it was still in the month of March, I am allowed a short reflection on the past year.

What I learned this year (in a nutshell):

  1. Synchronization in Dynamics AX is dangerous
    Let’s just say I learned that if the synchronization is taking way longer than it should be taking, it might be because it’s deleting every record in the database. #dataUpgradeIsFun
  2. Politics are important
    And so is management and project managers and other client-facing roles in the team. As a developer at a software company, you may feel you are the one contributing to the core business activity and you have the most important role to play. This year I learned and saw the importance of client-facing roles to get customers and users on board with the software and the processes.
  3. Regular Expressions
    Jamie Zawinski famously said; “Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.”. This happened to me this year, and I was left a bit disappointed with regex support in X++ (at least with the TextBuffer class).
  4. Unit Testing
    I read up all I can about unit testing from Microsoft and other resources. I had the opportunity to share my finding with our development team.
  5. Manual Testing
    I was asked to look into the options of automating our manual testing process. I am looking into third party testing automation tools build in Dynamics AX as well as Microsoft Test Manager. I went to a testing workshop at Microsoft Schiphol (NL) offices last week, and will unquestionably share a bit more about this in the future.

Review of last year’s goals:

  1. Understand InventoryPartly achieved
    I no longer quiver with fear when I hear “InventDim” or “InventSum” but I still have a long way to go. While I spend hours writing queries for a reservation type form based on inventSum, and can mostly figure out isolated issues with inventory, I don’t feel I have a good overview of the entire module and certainly wouldn’t feel comfortable explaining it to anyone.
  2. Learn the technical side of thingsPartly achieved
    I still haven’t read part 1 of ‘Inside Microsoft Dynamics AX’, but I have read isolated chapters in the book. I however do have a pile of whitepapers on my desk that I’ve read, including ‘Introduction to the SysOperation Framework’, ‘Testing Best Practices’, ‘Deploying customizations across Microsoft Dynamics environments’ and ‘Upgrade best practices’.
    I have also read a few chapters from ‘Code Complete 2’; a book on software construction I can recommend highly.
  3. Ask less help Partly achieved
    I have definitely improved a lot with this issue and disturb senior developers much less than in the past. Still, after reading this post by Ross Williamson, I feel I should continue working on this and strive to figure more things out for myself.
  4. Blog at least once a week Failed
    My last post before this one was two months ago; I definitely need to get my 22 draft posts published…
  5. Join a development real live communityFailed
    I haven’t joined a group yet; I need to work on this for next year.

Goals for next year:

  1. Learn the system technically and functionally (finally read ‘Inside Dynamics Ax’, learn MVC and SysOperation, understand inventory, the product model and of course AX7).
  2. Blog more.
  3. Do Powershell (I have this book, I have to read it and then use it).
  4. Be less awful by this time next year. (à la Steve Yegge and Jeff Atwood)
  5. Above all, be a humble programmer. (à la Edsger W. Dijkstra)

Be a humble programmer? The thing is, the more I learn, the greater the chance that I’ll lose sight of how much I don’t know. I’ll conclude with this quote by Dijkstra – may we all strive to learn more, stay humble and respects the limits of our own abilities:

We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers. – Edsger W. Dijkstra in The Humble Programmer (1972)

5 Goals for my second year as a Dynamics Ax programmer

Warning:This will be the most uninformative and least instructional post on the blog to date. This post is entirely personal and you can feel free to skip it. Otherwise, read on to be inspired!

Two days ago I posted the 10 things I learned in my first year as an AX Developer. Since then I have been thinking what I would like to focus on and achieve by this time next year. I feel that I need to post my goals here so they are public. This will hopefully add some pressure to accomplish them. In no particular order, I would like to:

  1. Understand Inventory I really find inventory in Dynamics AX difficult. I am not even sure what this entirely entails, but at the moment I quiver with fear when I hear “InventTrans”, “Batch”, “InventDim” or “InventSum”.
  2. Be better at the technical theory(for lack of a better description). I bought Inside Microsoft Dynamics AX R3 a few months ago and have successfully read the introduction. I don’t think I will be able to read the entire book in a year, but by next year, I want to be at least finish with part one.
  3. Ask less help. This sounds like an odd goal; I mean asking for help is completely normal. I am worried that I lean to strongly on others and avoid working independently. This goal is difficult to quantify, but I want to try to write down questions so that I can get an idea what the areas are I am technically or functionally lacking.
  4. Blog at least once a week. This is the goal I am working on this very moment. 😉 Of course, I do not want to write nonsense (like this post) simply to reach one post a week. At the moment I have tons of interesting blog post drafts, Windows Sticky Notes and scraps of paper. I want to work on them and get them out there. If all goes well I would also like to start some series of sorts.
  5. Join a development real live community.So far I have seen mostly groups aimed at Dynamics users. I want to find a group focused on development that physically meets in a city near me. If you know of any, please let me know in the comments!

10 Things I learned in my first year as a Dynamics AX developer

Today marks the end of my first year as a Dynamics AX developer! On the 1st of March 2014 I started working for a Microsoft Dynamics AX partner and I saw Dynamics AX for the first time. I had some development work experience before I started, but that was mostly maintaining very old VB and C# code.

I have learned thousands of things since I started! To keep it brief and celebrate how far I’ve come, here are 10 thing I learned about developing in AX this past year:

  1. I learned to write ternary statements. How I wrote software without understanding ternary statements is a mystery to me now.
  2. Ctrl + Arrow key moves the curser to the next word. This seem silly, but no one every taught or showed me this. I used to click with the mouse or move the cursor character by character with the arrow key.
  3. Developing in Dynamics AX is 90% searching and 10% developing. Even if you need to add one simple line of code, you will most likely spend 30 minutes looking for the correct class, table or form method to add the line, and then spend less than 3 minutes writing the code.
  4. It is much harder to find solutions and answers with Google. Not all of my colleagues agree with me on this, but I think it is because they have never googled for a Java or C# issue. With more popular languages you have a much bigger chance that someone had the same problem as you.
  5. X++, C#,  Java compared

  6. Since it is more difficult to find recourses and beginner guides, the easiest way to learn is from someone with more experience. I have completed Microsoft Development training and have read blogs, books and forums. They were all great, but I have learned the most from working one on one with a senior developer.
  7. No human being should be working on a computer without Ditto Clipboard Manager. This includes people who uses computers to write email and write in Word. I dare you to try it. It will change the way you copy and paste forever and make you wonder why Windows 1998 wasn’t released with a clipboard manager.
  8. Ditto

  9. It pays to write neat code. Write curly braces for every if-statement, indent properly and run a best practice check often.
  10. Triple check code when you copy methods from the sales to purchase or customer to vendor. Also, you should only be doing this if is impossble to use a map like SalesPurchLine or SalesPurchTable. A senior emailed me this screenshot.. oops!
  11. SalesPurchCopy

  12. Writing SQL like statements in X++ is simple and intuitive. I hoped this was a deprecated Axapta relic when I saw it the fist time, but know I know how simple and effective it is to find data in the database.
  13. I have learned that I still have a lot to learn. Working with extremely competent people with years of experience have taught me that this is only the beginning.