Full Stack Journey Episode #003: Jonathan Frappier

In Episode #3 of the Full Stack Journey podcast, I have the pleasure of speaking with none other than Jonathan Frappier. Jonathan blogs at VirtXpert, and is probably quite well-known for his role in wrangling speakers for the vBrownBag podcasts. Jonathan is @jfrappier on Twitter, and uses the same username on GitHub as well. Jonathan’s been in the IT industry for, as he puts it, “somewhere between 16 and 20 years.” Today, Jonathan and I talk about PowerCLI and leveraging the rest of your team at work to help with your success in making the journey to being a full stack engineer.

As with previous episodes, you can get the podcast recording from S3, or you can subscribe via iTunes. Browsers that support HTML5 will display a set of controls below that allow you to listen the podcast in your browser as well.

Show Notes

  • Jonathan has held a variety of roles in his IT career; he started out as a computer room operator
  • He believes a full stack engineer is a bit more than just a generalist
  • In his mind, a full stack engineer is someone who doesn’t punt the issue off to someone else. Instead, a full stack engineer is someone who is willing to help, who knows when to go ask for help (and who to go ask), and recognizes that no one person can know everything.
  • Willingness and a desire to learn are the marks of a full stack engineer
  • Jonathan’s journey to being “more” than just an admin started out with “hacking” together PowerCLI scripts to help do his everyday job.
  • It seemed to Jonathan that supporting virtualization and public cloud environments was the direction to head, and he needed to get a better grasp on software development. PowerCLI was a natural first step for him.
  • Syntax learning was his first hurdle.
  • Jonathan found success in coupling his learning efforts with his day job.
    • Uses a variety of tools (help desk tickets, Jira bugs, Kanban) to help keep his learning efforts on productive goals.
    • He also worked with his manager to look at upcoming projects, so that he could coordinate the project with his learning efforts.
    • Jonathan feels like it’s important to keep the business case and business benefits in mind when justifying automation projects to your management team.
  • He tried to learn Python as a second language, but that didn’t work out too well.
    • Why Python? The Python libraries for VMware were an initial draw for Jonathan, as well as a perceived interest in Python in the job market.
    • There wasn’t any synergy with the rest of his team—this made the effort very difficult.
    • He recommends aligning your own automation efforts with the technologies the rest of your team is also using.
  • The effort to use Python morphed into using Ansible.
    • This was a tool other on his team were already using.
    • The Ansible documentation site is great (one of the better open source documentation sites out there, in Jonathan’s opinion).
  • Have a project plan for what you’re trying to learn.
  • Don’t try to do too much…stay focused, stay specific.
  • Take advantage of your team! Divide and conquer. Learn from others’ mistakes.
  • Hands-on learning was really important for Jonathan. He recommends access to hands-on learning on some form or fashion for everyone (home lab, cloud resources, lab at work, etc.).
    • Currently working with some Ansible modules for VMware.
    • Also trying to work with Azure Stack.
  • Check public repositories for various automation tools—you can find great examples there!
    • Ansible Galaxy is especially useful for advancing your Ansible knowledge
  • If you find yourself pointing someone else in another direction, that might be an opportunity for learning. Walk over with them, listen to the conversation, and learn.
  • Jonathan uses Kanban to help organize his learning efforts and learning tasks.

Updated: