Transitioning into Tech: From Googling “What is Ember.js?” to Interning at a Software Consultancy

Maggie Gigler

Marketing Intern

Maggie Gigler

“Emma, have you ever heard of Ember?” I asked my roommate, a friend of mine from college who works as a user experience (UX) designer at a tech company here in Boston. I was looking for marketing positions and came across a software consultancy company called DockYard. I was drawn to their professional yet approachable feel: While they had built software applications for several big name clients (e.g. NASDAQ, the Democratic National Committee, Constant Contact), the language they used was straightforward and sincere. What’s more, they were a startup that didn’t feel the need to have the word “awesome” splashed all over their website, and their job titles didn’t include the words “ninja” or “jedi.” It was an exciting find.

At the time, I wasn’t familiar with Ember.js, Phoenix, or Elixir, which are several of the technologies we use here at DockYard in web application design and development. My background is in psychology and research, and I previously worked in the Department of Psychiatry at Massachusetts General Hospital (MGH). But I figured I’m a millennial, right? I grew up as the sophistication and use of the Internet took off on a global scale, and I can write HTML/CSS. If on one end of the spectrum you have my father, who is a businessman yet has neither an e-mail address nor a computer in his office, and on the other end you have your Mark Zuckerbergs and your Tim Berners-Lees of the world, then I fall somewhere in the middle. As I sat there wavering between the feelings of apprehension and audacity, I remembered my dad saying that the guy who leads the league in home runs usually also leads the league in strikeouts. So, I decided that I had nothing to lose and went for it: I filled out the “Join Us” form on DockYard’s website, and now I’m sitting here reflecting on my first thirty days as a marketing intern.

Being new can be awkward as you try to orient yourself within the organization, but you also have the unique opportunity to look at something from an original, unlearned perspective.

What I realized is that while I’ve always had a lot of respect for web developers and designers, I had never considered the future of tech in terms of the long-term viability of software applications or what that means for these roles. Admiration is not the same thing as appreciation, because to truly appreciate what someone does, you have to recognize the skill that it requires and the challenges facing that industry. It’s easy to take software and other forms of technology for granted without considering the engineering and design that have gone into creating them.

Prior to my interview at DockYard, I found it nearly impossible to find material that would explain Ember.js, Phoenix, or Elixir at a level that someone who was tech-savvy but not a developer could grasp (e.g., me). As I have an acute dislike of that left-out, lost feeling that accompanies not fully understanding a topic, I’ve been absorbing as many new concepts as I can while also learning about DockYard’s approach to design and engineering. What’s really impressed me in my first month is the careful consideration about the long-term viability of the applications we create.

One can further see the foresight of DockYard’s leadership in the deliberate technology choices that we make. For example, at DockYard we specialize in single-page applications that have an average shelf-life of ten years. The average iOS application that you purchase in the App Store, also known as a “native app” due to its installation onto the phone itself, has a shelf life of one to two years. This disparity is due to a variety of factors, including that the software has to be compiled specifically for that operating system, the expense of marketing a native app in hopes of climbing the App Store ladder, and importantly, the backwards compatibility of the JavaScript framework we use—Ember.js. It is noteworthy that this backwards compatibility is what precludes the issues that native apps typically face when new versions are developed, as it is a good demonstration of the web’s design as a platform to endure. On the backend, we employ Phoenix and Elixir, Phoenix being the framework and Elixir being the language. It’s ironic that the language we use for back end development is called “Elixir,” because DockYard’s ingenuity originates from the pursuit of sustainable progress as opposed to the industry’s panacea.

The experience for employees is no different from DockYard’s approach to design and engineering—transparent and uncomplicated. The value placed on communication was echoed during my first meeting with our CEO, Brian. When asked if there was anything I should be sure to do as a new employee, he said: “If you’re siloed in by yourself, that’s seen as a failure here.”

Looking over the past thirty days, I think my biggest fear was feeling embarrassed about my lack of software know-how on top of being a new employee. That being said, my difference in background hasn’t made me feel like the albatross of DockYard. Rather, what we have at DockYard is a unique kind of strength that is the result of the inclusion of people from different backgrounds and different skillsets. William Arthur Ward was quoted as saying, “When we seek to discover the best in others, we somehow bring out the best in ourselves,” and at least at DockYard, that’s incredibly true.


Stay in the Know

Get the latest news and insights on Elixir, Phoenix, machine learning, product strategy, and more—delivered straight to your inbox.

Narwin holding a press release sheet while opening the DockYard brand kit box