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 Inventory – Partly 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 things – Partly 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 for 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 community – Failed
   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)