I have described myself as a digital nomad on a handful of occasions (usually in a job interview because otherwise I hate talking about myself) but just recently took the time to examine what that means for me. The definition of a nomad is:

no·mad /ˈnōˌmad/

a member of a people having no permanent abode, and who travel from place to place to find fresh pasture for their livestock.

This is how I have interacted with technology in my life. I have developed applications in PHP, Ruby, Javascript, C#, Objective-C, Swift, Elixir, and even Go for a time. That is a wide assortment of languages from object oriented to functional, scripted to compiled, and a little of both in between.

Jumping around has both its pros and cons. Just like learning your first foreign language makes learning the next one that much easier, experiencing different development languages and the design philosophies that compelled their creators to bring them to life often helps you understand the next language even faster. It also can help you stay open-minded about different technology stacks, learning to value what each brings to the table while also knowing what the trade-offs might be.

A common pitfall is becoming a  “master of none.” You learn enough to be dangerous, but never reach that point where you have deep knowledge of the stack, the tools, or even how to interact with the community. You can certainly be productive, but you might miss out on some of the more intricate details.

For me, my different experiences have always managed to serve me well at the right points in my career for the most part. I was lucky to work with people whose respect I had earned and were willing to follow me on some of my journeys to completely overhaul the stack we were on. The reasons for the move were not always motivated by well thought out intentions. Sometimes I would become bitter at our current choices and my often ill-conceived perception of its failings would cause me to mount a coup, jumping to the stack I decided was the “good” one. Sometimes I just wanted change for change’s sake and would look for something new and shiny that I could dig into. While I count my love of learning as a positive quality I possess, it can also get me in trouble sometimes.

This is a story about my move to a language that I really love and wish I could spend all my time in, but have had to leave it, going back to some of those “old”, “lesser” languages and facing some hard truths about my decisions and where I see my career going.

It Begins‌‌

A few years ago, I found myself working with a pretty healthy mix of technologies. My company at the time was doing work in Unity for some R&D projects we were hoping would generate some interest in what our team could achieve, but we were also managing a client project that was in Ruby. I was surrounded by talented Front-end engineers, so I largely kept to my comfort zone on the server side of things.

I don’t fully remember the genesis of the project we would come to call Moriarty (shout-out to Nate for that name, still love it), but we decided we were going to build a social aggregator that everyone in the office would be able to see on TVs we had mounted in various common areas. The front-end was going to be built in EmberJS, a framework we had used before. I was tasked with creating the server application that would pull the stories and put them together in a form the EmberJS app could consume. I had just heard about Elixir from Dave Thomas, co-author of the Pragmatic Programmer, and a big influence in the Ruby community. I decided that this project needed to be built in Elixir. Couple of problems with that…

Running Before You Walk

First, I was the only one who had any experience with Elixir and that experience was limited at best. I was given a lot of free reign to do what I wanted but I was told that I would be going alone if this was the direction I wanted to go. This should have been a red flag for me. I could have chosen Ruby, a language some other team members had experience with, or better, NodeJS which almost all of the team had experience with. I can’t say my head was in the right place at the time; I was feeling like my work didn’t really matter, and I think I was looking for a challenge, so I forged ahead.

I spent weeks developing the Elixir app, using features I didn’t quite understand at the time (like umbrella apps), but when the dust settled, I was pretty happy with what I had built. It was fast, stable, and I barely had to do anything to it once it was finished. It was also a project I had total ownership over, for better or worse.

I ended up repeating this same process months later when we were building a connected VR game, again choosing to forge my own path, getting better at Elixir, but also secluding myself, without anyone who could actually review any of my code. That project also worked, but I had no feedback, other than that it met the acceptance criteria, to know if things could be better.

Living Your Choices

Several months later, I left that job after many years to try something completely different. I had never worked for a product team before; everything had been client focused. This would be the first time in eight years that I wouldn’t be filling out a timesheet, but instead would be focused on moving features across our kanban board. Even better, the tech stack included my beloved Elixir. I would be able to use the language I wanted in a professional environment with other engineers who could give me feedback and help me to improve my understanding of the language.

While I did get some feedback, most of my team were focused, rightly so, on our Ruby API that powered the business. While they were trying to keep everything running smoothly, I was getting deeper and deeper into Elixir and soon found myself as the expert in the room. Because of this, I ended up getting the chance to develop a new product, in Elixir, that would basically be all mine. I spent six months, and after all was said and done, I had created something I was incredibly proud of. As far as the technical side of my career was going, this was as good as it got. However, life has a funny way of wanting to have balance. While everything was going great with my coding, everything else seemed to be constant chaos.

As I have gotten older, I have realized that I carry a decent amount of anxiety with me. I get anxious about social situations that I am unsure about (often for no reason in the end) and I get anxious about the potential for a bad situation to form. So hearing news about the company that presented a certain amount of risk put a lot of stress on me and my family. It wasn’t something we were used to, uncharted territory, and largely cancelled out a lot of the professional satisfaction I should have been experiencing.

In the midst of all of this, I ended up doing something else that causes me a lot of anxiety and presented at my first meetup.


While I was so glad to have participated and shared what I had been working on, my biggest take away from the meeting shook me: I was one of two people in the room doing Elixir development professionally, and the only one doing it locally. This shouldn’t be that surprising; Elixir is a fairly new language, and Indianapolis isn’t a huge city, so the odds were not good there was a ton of people being paid to work in Elixir day in and day out. Regardless, it didn’t sit well with me. I was working at a company that was a risk, specializing in a language that no one was really hiring for where I lived. I could relocate or look for a remote job, but that can be much harder to achieve and my family was finally feeling settled.


So I left. I left that company and made a conscious decision to leave Elixir as well, and go pursue a new focus. It was a hard decision to make. I enjoyed the team I was working with, I enjoyed my product, I enjoyed the flexibility I had but it still left me wanting. It felt like something fun I was doing but I couldn’t see where the path would eventually lead. I was never going to be promoted, we were too small for that. I wasn’t working with anyone who possessed more knowledge about Elixir. It was up to me to push myself forward, which is something I have done for years with good success, but still left me missing some kind of mentorship. I realized that I had put too much focus on what technology I was going to be using and not realizing that at the end of the day, that wasn’t my highest priority when it came to my job satisfaction.

I go back to Moriarty and realize that I could have built that with someone instead of choosing my own path, and that is something I value more. I think back on my C# days and realize that I had mentors who helped me continue to improve. I realized that the aspects of my job that I needed were at odds with wandering on the fringes. Mentors, peer-review, working as a team; they all outweighed being able to use the technology I was currently interested in.

Being True‌‌

It took some struggle and self-reflection to realize that what I thought was important to me actually was not and that was why I wasn’t feeling complete in my work. Taking an inventory of what is important to you, what gets you excited to take on a project, is advice I wish someone would have given me as I was starting off in my career. If you are really energized by the idea of working on an open source project, engaging with the community, then make sure you find opportunities where you can put energy toward that end. If you want to work with a great team and have mentors who can help you grow and become an even better developer, make sure you are in a place with puts an emphasis there. If you want to work with the newest, shiniest thing out there, great! Seek out those communities and support and have fun.

I am not leaving Elixir forever, and I am not going to forego learning anything new that comes along; that is not who I am. They will just be side projects instead of my day-to-day work, and I am actually excited about that. I also certainly wouldn’t turn down a great Elixir experience in the future, but now I can go into it knowing that I need more than just being able to choose the language.