Episode 123

Last updated Sep 19, 2022 Edit Source

Welcome to episode 123 of the Nerd Journey Podcast @NerdJourney! We’re John White ( @vJourneyman) and Nick Korte ( @NetworkNerd_), two Pre-Sales Technical Engineers who are hoping to bring you the IT career advice that we wish we’d been given earlier in our careers. In today’s episode we share part 1 of our interview with Josh Duffney and discuss his early career progression through learning PowerShell, participating in technical communities, becoming a PluralSight author, and making an interesting transition from Systems Administration to DevOps Engineering.   

Original Recording Date: 05-03-2021 

Topics – Early Career, Learning PowerShell, Community Participation, PluralSight Author, Sacrifice, Systems Administrator to DevOps Engineer  

=========================== 

• Josh Duffney is a Content Developer for Microsoft.  He writes content on docs.microsoft.com and focuses on Ansible, Terraform, PowerShell, and Azure CLI.  Josh Duffney #Microsoft

• Josh works with a Product Manager for each technology stack mentioned.  Some of the documentation is based on customer feedback, but there is also a great deal of freedom to shape the content roadmap. 

• Josh has been with Microsoft for about 4 months. In the last month, he has spent time doing analysis of documentation in the Ansible space as it relates to Azure. 

• Josh works with Product Managers and Technical Writers and can think of his writing beyond a blog post series and more from an information architecture standpoint. 

• Content development is still development.  They use software development principles to build and release documentation.  Instead of building infrastructure, Josh is building documentation. 

• Nick and Josh crossed paths originally in the Spiceworks community. 

• At a previous employer, Josh was working on a disk space report which his manager expected daily at 8 AM via e-mail. 

• The server in question ran everything for the business including e-mail, print services, and acted as a domain controller.  Josh had to login to the server daily to pull the needed information to put in his report. 

• Josh saw this as a mundane task and vented to the Spiceworks community.  Someone suggested he script the task and run it on a schedule, which worked great.   

• After seeing he could do so much work with code, Josh was interested PowerShell. 

• Josh then transitioned to working at a large construction company near where he lived in Bellevue, Nebraska. 

• He was part of a large help desk team and deemed one of the two “script kids.” 

• The team would often get tickets that involved making changes for hundreds of users at a time.  Writing scripts made this much easier and sharpened Josh’s skills. 

• In previous roles Josh was a one man department and didn’t get enough repetitive tasks for a good handle on scripting. 

• The script kid title was a slang appreciative term for what Josh and his teammate saved the tier 2 team in terms of workload.  There was no specific direction on what they should automate, but they jumped at anything and everything they could touch with PowerShell (Active Directory, Sharepoint, etc.). 

• The help desk team was the ingress of technology related tickets for the entire company.  The level 1 and level 2 teams would handle whatever they could and escalate to other dedicated teams when needed. 

• Working as part of this help desk team exposed Josh to all the layers of technology and provided a broad range of experiences. 

• Josh had a big goal to get into the network team and was studying for his CCIE.  He had taken it two times previously and failed but later passed when he took it for the 3rd time.   

• But after getting the certification, Josh found himself focusing on PowerShell. 

• After about 8 months of working the help desk, Josh applied for a Systems Engineer position.  This involved managing SCCM, operating system deployments, and application installs. 

• He scripted as much as he could with PowerShell. 

• This was about the time Josh got into the PowerShell community. 

• He started automating both driver deployment and application deployment with SCCM as the delivery vehicle but PowerShell as the automation behind it. 

• This role was more project based to a degree than working the help desk and gave Josh the opportunity to hone his skills a bit more. 

• Josh’s career really began in the Spiceworks community. 

• Josh’s first job out of college was working help desk for a small engineering firm.  His firs project was to choose a new ticketing system platform. 

• He chose the Spiceworks Help Desk Platform and immediately got involved in the community. 

• Josh’s boss was a firefighter and was not in the office much.  Leveraging both the Spiceworks community really helped him learn how to use many new tools within the environment. 

• He considers the Spiceworks community as well as the PowerShell community incubators for his career. 

• Adding a second community to his repertoire provided “more things to chase” and more people to learn from.  

• One of Josh’s favorite books is Give and Take by Adam Grant.  At the very top and very bottom of reciprocity models is the giver. 

• Josh looks to participate in communities where he can be a top giver but also reap the benefit of participation in the greater community (i.e. a selfish giver as Josh calls it). 

• You can only be a lurker for so long in a community before you start giving.  But once you contribute something others find helpful it fuels you to keep doing it. 

• One of the first few how-tos Josh wrote in the Spiceworks community had to do with imaging a Windows 7 machine with FOG.  

• Josh mentioned even 7 years after he wrote it, people were still commenting on it.  To see this was extremely rewarding. 

• There was less hesitancy to start participating in the PowerShell community when Josh joined. 

• It was not a big forum site like Spiceworks. 

• Josh heard about Microsoft TechEd (the predecessor to Microsoft Ignite) and started watching the sessions online.  He noticed presenters listed their Twitter handle and later decided to start being active on Twitter too. 

• Josh started following every Microsoft MVP who had PowerShell in their bio. 

• He started interacting with people on Twitter and answering questions, feeling more comfortable reaching out to people directly over time. 

• Participating in these communities provided some validation that his ideas were worthwhile. 

• When you are the youngest / most junior person on a team, getting the social validation of your ideas from communities makes you more comfortable being an idealistic person willing to share with your teammates at the office. 

• Sometimes this type of validation can give you the confidence to go and do the next thing, get the next job, etc. 

• Josh mentioned this gave him permission to keep redefining what he wanted for his career. 

• Right after college, Josh wanted to be a game designer but decided not to go into debt to study in this field.  He had also convinced himself that he did not want to be a programmer. 

• He chose the community college path and dove into the work force, really enjoying it. 

• Josh later found that he did like coding after all, and as he started to learn he started to teach, which gave him confidence (even in interviews). 

• Listen to Josh’s story about an interview process in which every interviewer had read some of his content (blog post or Pluralsight course). 

• Once you begin to develop public artifacts, they start to be your resume.  And these public artifacts gave Josh the confidence to redefine what he wanted to do in his career. 

• This gave him enough feedback to determine what is both valuable and interesting to him. 

• Are we all building the resume by producing public-facing content / a body of work? 

• Answering questions in communities is a great way to validate that you have something to share.  The Spiceworks community, for example, allows users to create [projects}(https://community.spiceworks.com/people/duffney/projects) attached to their profile. 

• “You’ll never go wrong by just adding value.” - Josh Duffney 

• Looking back, Josh realized writing had always been part of his story since that first how-to in the Spiceworks community. 

• Every time Josh went to write something in Spiceworks (how-to, answer to a question, make a comment), he tried to add value.  Using this as a north star will guide you in creating public artifacts and determining if you should write them in the first place. 

• There is a slippery slope with self-promotion and marketing in the online content game, but keeping focus on adding value will ensure you don’t stray too far. 

• Community Moderation - 20:47 

• A common theme in Josh’s career is that people have pushed him to do things.  While attending a SpiceCorps meeting, someone who was stepping down from their role offered Josh the chance to become a moderator (to which Josh said yes).   

• After a certain level of activity, these opportunities present themselves in different ways.  Josh was honored to be asked but really enjoyed that leading capacity. 

• At the beginning of your career, you say yes to everything to become successful.  In the middle and toward the end of your career you say no to almost everything.  Josh believes this advice came from James Clear.   

• Josh points to this as a form of leadership that was not management, which seems to be a common theme throughout his career. 

• Josh has never really wanted to manage people, but he does try to lead by sharing ideas or bringing people together. 

• This tendency along with the opportunities being made available to him explain how he fell into them. 

• Nick was reminded that he’s been wanting to read Will Larson’s Staff Engineer book. 

• Josh built courses for Pluralsight.   

• He started as a consumer of courses, but something happened at a local PowerShell user group.  Josh ran into an instructor from a Pluralsight course he had taken.  He loved the instructor’s approach to teaching and asked for advice. 

• At work, Josh had done some instruction to help colleagues.  He thought perhaps creating courses was a way to make some extra cash. 

• Josh originally asked about becoming a certified Microsoft instructor but was encouraged to become a Pluralsight author, which Josh initially dismissed. 

• Around this time Adam Bertram came onto the scene. Josh watched some of Adam’s courses and thought “maybe I can do this.”  He reached out to Adam for some guidance. 

• The process to audition was to record 5 minutes of yourself presenting and send it in for consideration.   

• At the time, Don Jones was the curriculum director.  Josh was somewhat star stuck about having to audition for Don and had to push past the feeling of impostor syndrome. 

• Josh ended up authoring a few different courses. 

• In the beginning, an author could define the course as they wished or choose from a catalog.  There are many more courses in the Pluralsight library now than 5 or so years ago when Josh got into it. 

• Pluralsight also has a better pulse on what their customer base need these days. 

• If you can fit into their catalog, it could be a great career boost as well as a nice monetary incentive. 

• This is a legitimate part-time job for the duration of your work authoring courses.  Josh said for his first course every minute recorded took an hour of prep and production work. 

• The instructor would also need to prepare all demo environments and any slides to use during the course.  Josh mentioned building the infrastructure as code environments for his courses were tremendous learning experiences. 

• There is a good technical team at Pluralsight to help check sound levels and ensure the highest quality content is produced. 

• The marketing burden for your course is relieved as Pluralsight would do it for you. 

• After saying yes to everything, you eventually reach a point of not being able to sustain it all.   

• Josh says 2021 has been a big lesson for him.  Knowing what you want most is important. 

• In many ways he has decided not to decide. 

• Is continuing what I am doing going to get me to the level of success that I want? 

• Josh has reached the goals he set when he was 20 for achieving by age 30 and has worked to redefined how he wants things to look at 40. 

• Certain things may have diminishing returns. 

• For Josh, to achieve a writing project goal he has, he will say no to all freelance work in the next 6-8 months. 

• In that one statement, he is deciding not to decide. 

• There were a number of Pluralsight courses that were in line with Josh’s expertise and interest that he had to turn down because of this. 

• Find clarity by thinking deeply about what you really want.  This takes time. 

• Josh has taken the better part of a year thinking about what trade offs would be present switching to more of a writing role as opposed to an engineering role. 

• Sacrifices must be made to make room for other projects. 

• Nick references some advice from High Performance Habits by Brendon Burchard that sound similar to what Josh has done. 

• Find your primary field of interest (PFI), and then focus on creating prolific quality output (PQO) with a large percentage of your time, saying no to things outside the PFI. 

• Josh saw this as a natural progression after starting with the help desk position we discussed earlier.   

• After this he became a Systems Engineer and worked on SCCM, progressing to Senior Systems Engineer at a payments processing company focusing on Active Directory. 

• This was the first team Josh was a part of where everyone was a scripter in some way.  It allowed Josh to build his own solutions as a developer. 

• For example, Josh wrote scripts for Active Directory migrations and tracked all changes in a SQL database (leveraging this for reports to upper management as well). At one point he had a Microsoft consultant look at what he built over an 8 month period.  Josh was told a consulting firm likely would have charged half a million dollars or more to build a system like that for his company. 

• To build this system, Josh spent time after hours working on it, collaborated with peers in areas where he lacked skills, and read a number of helpful books.  

• At the time, Josh was really interested in what it would require to take his coding at the next level without needing to move into a junior position as a software developer.  He wanted to deal with infrastructure and saw DevOps as that path which allowed him to walk the fine line between developer and engineer. 

• This allowed him to leverage previous experience in Systems Administration.  He had delved into CI / CD pipelines, Desired State Configuration Management, worked with Octopus Deploy to roll out configuration management, and stumbled into Ansible. 

• There were eventually barriers beyond administration, and Josh had to read up on DevOps literature (gaining insight on process, culture, etc.). 

• Josh doesn’t really see much of a difference between an IT Admin and a DevOps Engineer other than the way you carry out your work. 

• Josh has heard of teams working together in a Modern Ops fashion, but it depends on the organizational design. 

• Even traditional IT shops can bring in some DevOps practices to improve processes. 

• In Josh’s first role as a DevOps Engineer, they were essentially release engineering until they started taking on more infrastructure tasks.  They acquired the Systems Administrators as part of the DevOps organization at that time. 

• Josh cites a good book called Team Topologies that breaks down different team structures.   

• Listen to Josh’s description of the different topologies. 

• He feels the SRE model is an implementation of DevOps and gives some feedback on how he has seen SREs interact with various teams inside an organization. 

• When people ask Josh for feedback on DevOps Engineer roles, it is hard to do so without knowing the organization structure.  If the tech stack lines up maybe give it a try, but you likely cannot know the full picture until you join. 

• For Josh, the gateway to DevOps was infrastructure as code and cloud. 

• If interested in walking the path to DevOps, start with a programming / scripting language.  This creates a way for you to communicate with developers. 

• Also, you can use the same tools to manage your infrastructure automation as the developers do their code (Git, CI/CD pipelines 

• The Systems Administrator likely has a solid background in infrastructure.  Leverage it by learning how to automate it completely (i.e. server build to full configuration). 

• Getting to either immutable infrastructure or mutable infrastructure with config management would be Josh’s first step toward the DevOps world. 

• Choosing a scripting language for success will likely rely on mental models.  Someone strong in Linux may choose not to dive into learning PowerShell first and may be more inclined to look at Python. 

• Listen to Josh’s story about working for a company that was moving toward AWS and what he had to do to learn it based on his own mental models.  

• Once you get a good foundation in a language, then focus on other tools like Ansible or Terraform.  Anything shoved into a cloud shell could be a good tool to target. 

• Some configuration management tools are falling in popularity because of the infrastructure they require. 

• “Learn enough to practice.  Practice until you understand.” - Josh Duffney 

• Josh came up with this out of necessity.  He thought he needed to master everything he picked up.  It’s better to aim for competence first.  Then decide whether you want to pursue mastery. 

• Spend a significant amount of time on one area / one tool rather than a little bit of time on all.  There will be a significant amount of bleed over as you get into other areas. 

• Don’t be afraid to become competent in other things after you’ve gone deep in one area.  You don’t have to dive straight into mastery. 

Contact us if you need help on the journey.