Developer at Velir; Sitecore MVP
Tell us a bit about yourself and how you got started?
I’m from Sudbury, Massachusetts. I studied computer science and psychology at Connecticut College and began working as a .Net web developer after graduating in 2014. I started working with Sitecore when I joined Velir in 2016, and I am currently a full-stack developer in Velir’s Managed Services department. I first became a Sitecore MVP in 2018, in part due to my Sitecore module, the Content Export/Import Tool, which I created to accelerate data exports and content entry in Sitecore.
What does a day in the life look like for you?
I have five accounts that I regularly work on, as well as occasionally helping with large projects. In my department, because we are maintaining older websites (often built by other agencies), there is a lot of variety among my sites; I’ve got four different Sitecore versions currently, with the oldest being 8.2, and the differences in Sitecore versions, as well as unique codebase structures and very old legacy code, provides unique challenges in development. Some of my sites have very basic css and Javascript, while others have complex React modules. I get to work with a wide array of backend and frontend technologies. I also handle deployments to production and handle urgent issues such as site outages.
After work is over, I have a number of hobbies that keep me busy. I take an aerial silks class once a week, and I make art that I sell at local oddities markets.
What would you say is key in exceling in your industry?
It’s critical to be able to learn and adapt, as web technology is constantly evolving. Be aware of what new technologies are being adopted, and take advantage of opportunities to use those new technologies. If you can’t dive into new tech in your free time, then ask to be involved in work projects that utilize it. If you learn about a cool new technology that your company isn’t using yet, share it with your colleagues and suggest a place where it could be implemented.
Share your knowledge. One of the easiest ways to make a name for yourself is to blog about technical problems you’ve encountered and how you’ve resolved them. If one person finds your blog post or Stack Overflow question helpful, then it was worthwhile, and you never know which posts are going to blow up in popularity; something that you assume is too obscure a problem or too obvious a solution might actually be an issue many other developers need help with. If it took you more than a few minutes of Googling to find an answer, it’s worth writing about.
What challenges do you see for women in tech today?
My biggest challenges have been internal. When I first started my career, I was younger than all of my coworkers, and one of the only female programmers. I felt like everyone was smarter than me, and I was afraid to speak up with questions or opinions because I didn’t want to make myself look stupid. The people around me were very supportive, but I limited myself due to my insecurity. It was a challenge to overcome, and it would have been a lot harder if I didn’t have great colleagues who have encouraged me and mentored me.
People of any gender can feel imposter syndrome, but I think it’s especially common for women in tech since it’s a male-dominated field, and it can be hard to make yourself vulnerable when you feel like you are a representative of your gender. Simply having more female developers in your office does a lot to alleviate this pressure.
Do you have any advice or tips for women looking to start their careers in tech? What do you wish you had known?
Be confident in your skills and your knowledge. The people around you are not smarter than you, they’re just more confident/experienced. Imposter syndrome can make you reluctant to ask questions (“surely I should know this already”) or to share your knowledge (“everyone else must already know this”). But, asking questions is critical to growing as a developer, and can also help you form personal bonds with your colleagues. Don’t be too hard on yourself if you struggle to understand something. Some areas will be harder for you than others, and different people learn in different ways (I’m very hands-on, and often have trouble understanding new concepts until I get to work with real examples). Code, as well as documentation, should be easy to understand, and if it’s overly obfuscated, that’s a failing on the part of the writer, not you.