Fun fact: before transitioning to the Digital Project Manager career, I spent ~6 months out of the year traveling internationally for work (for an amazing organization called Engineering World Health – yes, I’m biased, but check it out!).
This meant I spent a lot of time in countries in which I did not speak the local language (including Kinyarwanda, Swahili, Khmer, Nepali, and Mongolian). Before each 2-3 month trip, I’d learn some basic phrases (you know, the classics: “Hello,” “Where is the bathroom?”, and “Please, stop the bus, I need to get out!”). However, I found that for each new language, it took about a week for my ears to adjust to the new sounds and patterns so that I could reliably pick up words and phrases.
I’ve found that the same principle applies to working in web development. In my last blog post, I wrote about Learning to Speak Drupal. Now, I’m reflecting on how learning the basics of the command line, git, and frontend languages made me a better advocate for clients, development teams, and a better project manager as a whole.
Since I’m both perpetually curious and respectful of my coworker’s time, I looked to a free, open-source code school called The Odin Project to begin learning the “basic phrases” of web development. The Odin Project teaches Ruby on Rails as a backend language and framework, while Savas works primarily with PHP/Drupal. However, I still found it to be a fantastic roadmap for learning the basics.
I started with the Web Development 101 course and would recommend it to anyone who prefers learning by doing (and failing and then doing again…). While working my way through the course, I built this groovy etch-a-sketch.
I had a blast and grew a whole new level of appreciation for Savas’s supportive frontend squad.
But that’s all just fun and games.
For my day-to-day job, the most valuable skill I’ve developed is comfort using the command line and git. One of my favorite ways to help my team is by removing blockers and addressing bottlenecks. Sometimes this is best done through project planning and capacity planning, and sometimes it’s best done by rolling up my sleeves and filling a needed role.
The way I see it, project managers are the ultimate team players. Providing timely, manual QA of a bug fix branch before code review and deployment to a staging site is one way that I’m able to help keep projects running on time and unblock team members. Other times I’m able to help troubleshoot – or, let’s be honest, at least recreate – a local stack issue.
I’m also able to confidently answer questions including:
- What’s the difference between a codebase and a database?
- What is a merge conflict?
- What are the actual steps required to stage work for client review?
Savas is developer founded and developer managed. It’s one of the things I like most about working here, and it jives well with my curious nature and technical tendencies. Learning just a tiny bit of programming has made me more confident in my ability to contribute to the work we do.
I never became fluent in Kinyarwanda or Nepali, but I did learn enough to get around and occasionally impress the locals. I think about programming in the same way. While I may never become fluent in CSS or PHP, I’m learning enough to do QA locally, spot a complex feature request, and occasionally impress developers and technical clients with what I’ve picked up along the way.
One of my main goals in life is to expand my comfort zone (professionally, and otherwise). Next on my list? I’d like to improve my vocabulary for the design phase of projects. I’ll be starting with reading Articulating Design Decisions, by Tom Greever, which comes recommended by Savas designer, Sean.
I’m always on the lookout for resources to expand my vocabulary and expertise. What do you do to expand your professional comfort zone?