The impact of coding

I have spent a lot of my time over the last year going from a total novice with programming to actually being comfortable with Powershell. As someone who has come from a CLI networking background I did spent a lot of time inside devices but never had the chance to automate my workflows. Nor was there a need in a previous life.

I feel I have contributed a little bit to PowerNSX. I have made some useful scripts for myself. I wrote a fair smattering of documentation over on the [website](http://powernsx.github.io) and tested the be-jeebus out of it on Windows. This test shifted to the macOS distribution. My thinking and approach to scripts changes as I coded. My first forays into scripts were blind, ill-thought out, with a focus just to GSD!

SDDC-Lockdown, the deployment of a security model for the entire VMware stack in a provider/consumer model, was where I had an awakening. The premise of SDDC Lockdown was the following:

* Develop a provider / consumer model for firewall policy

* Allow lifecycling of any component without a change of security model

The goal for this was to be automated completely from user input of content to deployment of required objects. In addition factors such as dependencies, unknown inputs, order of operations, and PowerNSX not covering everything just yet all made it a great thinking exercise! Between coding all the things then actually trying to use it I realised that my first iteration didn’t work. I coded, deleted, refactored, coded some more, deployed, destroyed, coded, and refactored. This little project I realised could become quite modular and that changed the way I approached the deployment. Oh! Do not forget to make your code portable and reusable too!

Reflecting on it made me realise there is an art to coding that is more than just knowledge.

Slowly I have moved from creating crummy little scripts, opening PR’s and pestering Nick to fix to opening PR’s, **thinking* about the issue, and developing new cmdlets. Now it is not just Get and Delete commands. These are somewhat easy once you get the hang of it. What really started to make me think (with input from good mentors *cough* Nick again) were the Set commands.

Here is my first attempt at making a *set* cmdlet. These generally are trickier than get and remove. This involves using a basic cmdlet to retrieve the data from the NSX Manager. `Get-NsxFirewallThreshold` is the command in question.

This initial attempt allowed me to create an XML body from the three properties according to the API Spec defined for NSX.

The API spec by default requires the user to specify CPU, Memory, and ConnectionsPerSecond every time a new change is created. Whilst this makes sense technically from a usability point this isn’t logical.

* What if I just want to change the CPU value?

This will mean I will need to collect the values in `Get-NsxFirewallThreshold` and record the values to manually define them as parameters in `Set-NsxFirewallThreshold`. This is cumbersome and some additional logic

After a few iterations here is the final commit. This was a great learning exercise. Thinking about the cmdlet you are creating coupled with how it being used would definitely saved me a few iterations. A shoutout to Nick Bradford for the mentoring and the prods to make me think about this different and ultimately be a better coder.