"The Best Programming Advice I Ever Got" with Rand Morimoto
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Name:
Rand Morimoto
Programming and Job Experience:
I've survived the shifts and changes of this industry for the past 30-years, most recently working with Microsoft technologies 2-3 years before the products release to the public. With this huge jump in helping early adopter enterprise organizations implement this stuff in production environments, when the stuff finally does ship, people think I'm really smart or something. It's a big career advantage, and I enjoy sharing this knowledge and experience with others through books, blogs, public speaking sessions, and the like. In my free time I run a 65 person IT consulting firm (Convergent Computing) based in the San Francisco Bay Area, and I'm a Trustee on the governing board for Saint Mary's College, a fun blend of technology and academics to keep my brain working.
Most Notable Achievement:
I got my start in the computer industry being held upside down, with an oven mitt in hand, replacing vacuum tubes in IBM mainframes and got a taste of career obsolescence when solid state computers replaced vacuum tubes. AND I got too big to be held upside down! I now work hard to make sure to keep a step or two ahead of the obsolescence curve in the industry.
Most Frequently Used Programming Language/Development Platform:
Microsoft PowerShell
Advice:
As much as I have done a lot with the Microsoft line of products over the years, whether that's with Windows, Exchange, SharePoint, or the like, the best programming advice I was given by one of my long time peers was to "learn PowerShell." In the early days of PowerShell, it seemed odd having a product like Microsoft Exchange that had been great with the Graphical User Interface (GUI) for adding mailboxes and doing administrative tasks — Why shift to PowerShell to do things? AND, in those early days, everything that could be done through PowerShell could actually still be done from the GUI, so why learn a scripting language to do things I can do from the GUI?
BUT, now that we're a good 5-yrs later, I'm really glad I picked up PowerShell. Now when we're doing things with Exchange 2013, or Office 365 in the cloud, there are MANY things that can only be done through PowerShell. There's no GUI to do core functions, AND when doing repetitive tasks like migrating mailboxes, creating servers, or the like, PowerShell is WAY more efficient to do the same thing over and over!
So I'm really glad I was given advice to "just learn PowerShell."
With this experience of PowerShell under my belt, with the latest in Windows 2012 and Exchange 2013 having expanded cmdlets to be able to simplify processes beyond just the "admin" tasks of user, mailbox, and connector creation, I'm using PowerShell even more! As an example, server hardening has always been a mundane task that required the execution of group policies or scripts that can now be done through PowerShell scripts, and the great thing about PowerShell is that the scripts can be run across different versions of Windows as well as remotely to systems not even in hands' reach.
Even knowing PowerShell over the years, as Microsoft introduces the latest versions of Windows, Exchange, SharePoint and the like, I've been able to continuously update my thinking on how I can now do things through PowerShell that I possibly could not have done (or done as easily) just a few months ago.
The advice I'd pass on is to start writing down PowerShell commands and sequences as you do things, and little by little shift to doing things with PowerShell instead of the GUI. It doesn't take long, especially on a normal month where you end up having to do a lot over and over; once you get proficient at scripting, you'll wonder how you EVER did anything the "old fashion way" using the GUI. That's what I did when it was shared with me to "Learn PowerShell." Hope this helps as well...