Laziness is my superpower. I can't stand tedious, manual processes, and the quicker one gets on my nerves, the quicker I start mentally sketching out a way to automate it. Here are five things I've created to make someone's life easier - usually my own, but most had the side effect of benefitting others. The first four are all from my most recent role, the fifth is from a prior one.
When our Mac fleet was still bound to on-premises Active Directory, I found myself getting tired of having to remote into a Windows jump host to handle AD account unlocks and password resets. I was never a fan of the Active Directory Users and Computers module either, with that cutting edge 1990s user interface that I can only assume was designed by someone who never had to actually use the thing. To eliminate these particular annoyances from my life, I wrote a utility script in just under 400 lines of Bash to handle common AD activities directly on my Mac. It called Apple’s dscl (directory service command line) utility, and leveraged CocoaDialog (this was before the more modern swiftDialog existed) to give it a convenient GUI. To make things even easier, I created the correct folder structure around the script so macOS treated it just like a normal GUI application that could be run by double-clicking its icon or putting a shortcut in the Dock.
I could search by last name or username, and if there was more than one hit on a last name I’d get an alphabetized popup menu listing names next to usernames to ensure the correct person was chosen. The main window showed if the account was locked out, and if it was, the time of lockout would be displayed as well. It also showed if the account was expired (we used a lot of freelancers and gave them expiring accounts), the date of last password change, and how many days were left on the current password before a change would be required. An “Unlock” button would be presented only if the account was locked out, but a “Password” button to set a new password was always present. We had to use separate admin-level accounts to do anything in AD, so I added in the ability to store the admin-level credentials in the macOS Keychain. The script would also alert me if my admin-level account's password was expired or getting close to expiration. Once finished and tested, it was quickly adopted by my Mac engineering team plus every deskside support tech who used a Mac as their daily driver. It remained in use until we switched to Jamf Connect and stopped binding our Macs to AD. It saved everyone at least a couple minutes per interaction with AD, since the jump host wouldn't let us just stay logged in with an idle session all day long until we needed to access it.
Back when our ThinkPad fleet still used removable batteries, a directive came down to check the battery capacity of units returning to inventory after employees departed the company. We had to open an elevated command line window, run a WMIC command, dig through the mess of output to find the current charge capacity and the manufactured capacity of the battery, and use those values to compute the percentage of capacity remaining. If it was below a certain threshold, we were to replace the battery before redeploying the machine.
I think I did the manual process twice before I got annoyed and began my search for an easier way. It became evident that PowerShell would be the way to get it done, so I learned just enough of it in my downtime to accomplish my goal. Pretty quickly, I had a small script that would pull the relevant info and compute the percentage in the command line window. I decided to take it a little further and slapped on a GUI. When run, a small window would pop up showing the results: a green background with PASS in large letters, or a red background with FAIL, with the actual percentage displayed below in a smaller type size. When I found having to right-click the script file and choose "Run with PowerShell" from the context menu to be unnecessary friction, I discovered ps2exe and used it to compile the script into an .exe file so it could be double-clicked like any other Windows program. I showed it to my manager after a couple days of testing it out, and within two days of him seeing it the entire team was directed to use it to shave some time off the processing of each returned ThinkPad.
We had a long-standing issue with our outsourced service desk's poor handling of Mac users: their knee-jerk reaction to nearly every Mac problem was to reset the user's password in Active Directory. When we still had our Macs bound to AD, this would break the sync between the user's FileVault password and their network password, i.e. when they rebooted they would need to enter two different passwords to reach their desktop.
Fixing this was a manual process that required hands-on intervention by a support tech who had to perform several steps on the command line, using the fdesetup utility. Fueled by my annoyance that the service desk was throwing roadblocks in front of the users and creating unnecessary work for the deskside techs, I rolled up my sleeves and figured out a way to automate most of the fix with a script. The user would still need to be walked through logging into their machine using their previous password and new password, but once they reached their desktop they could simply open the Jamf Pro Self Service app and run my script.
When the script ran, the user would be asked to enter their current network password twice to ensure correctness. Next, the script would delete their FileVault user account, confirm the deletion, recreate it, and confirm successful recreation. If successful, their FileVault password and network password would be back in sync and they would get a dialog telling them so. If the validation failed, the user would be directed to immediately contact the service desk and escalate their ticket for manual remediation, with an explicit warning that if they rebooted their machine before the problem was addressed they would be unable to log back in without assistance. Fortunately, this was a rare occurrence.
Back when we migrated from on-premises Exchange to hosted Exchange, Microsoft had a mechanism for Outlook on Windows machines to automatically switch to the new Exchange server settings, but nothing for Macs. At the time we had over 700 Mac users spread across more than a dozen offices in several countries - far too many users for our service desk and/or local deskside support techs to handle manually. Giving instructions to the users and asking them to change their own settings was also a nonstarter.
I worked with the Exchange team to obtain the correct hosted Exchange settings, developed a hybrid Bash/AppleScript to handle the migration, and tested it rigorously. When users were migrated to the new Exchange server, they'd also be placed in a specific Active Directory group. My script would check to see if the user was in that group, and if they were it would pop a dialog telling them their Outlook was about to be reconfigured. The AppleScript portion of the script would then access their Outlook account settings, find their Exchange account, and update the settings for the new server accordingly. Next, the script would delete the saved credentials for the previous Exchange account from the user's Keychain to prevent Outlook from getting confused - an issue that cropped up in testing. Finally, it would pop another dialog to report success, or alert the user to contact the service desk for assistance. On success, it would also drop a marker file so it wouldn't try to run the migration again.
Campbell Soup Company was a client of my employer, and I was tasked with supporting some of their teams that used Macs. Their Structural Packaging Design team had a Mac fileserver that stored an archive of all their packaging design drawings, and people in other departments frequently needed something pulled from that archive for one reason or another. The way things were originally set up, the packaging engineers would have to search for the requested files and manually send them to the requestors. This was not a good use of their time, so they asked me to find a way to automate it. I found a shareware utility called FindFilesX that was highly controllable with AppleScript, and wrote an AppleScript CGI application around it that gave their archive server a web interface to use it. From that point on, people who needed any files pulled from the packaging archive could search the server themselves from their own computer and easily obtain what they needed without the packaging engineers getting pulled away from more important tasks.
In the early 2000s I wrote a very lengthy and complicated AppleScript that pulled my email from Microsoft Entourage and presented it in a web interface that basically duplicated Outlook Web Access as it existed at the time. I wrote it mostly as a learning exercise and out of curiosity to see if it could be done. It worked, but it was much too slow to be practical.
I have a small collection of AppleScripts and Bash scripts I wrote to make managing my iTunes library easier (I still buy and rip CDs and manually curate my music library). My favorite is still a work in progress. It builds a list of songs from a few playlists, and then I manually run rsync against that list to copy them to a Raspberry Pi in my kitchen running a music player script I wrote. Eventually I'll automate the syncing and give it a GUI with swiftDialog.
Most recently, I got annoyed at having to open the Home Assistant app and manually turn on the lights over my basement workbench, so I took about 20 minutes to write a script and a launch daemon. Now whenever the resolv.conf file changes on my MacBook due to a networking change, the script fires. It looks to see if the MAC address of the default network adapter matches that of the ethernet port in the USB-C dock on my workbench. A match indicates that my MacBook is connected on the workbench, in which case an API call is sent to Home Assistant to turn on those lights. Now I plunk my laptop down on the bench, plug in my dock, and the lights above the bench come on before the external monitor even wakes up.