My First Year at Enigma

My First Year at Enigma
By

This July marked an amazing milestone in my life: my first year in the working world. Last summer I started as a software engineer at Enigma, a fast-paced, innovative, data linking solutions startup in New York City. Over the past year I’ve learned a lot, from where the best snacks are hidden to why everyone has a love-hate relationship with Jenkins (and what Jenkins even is). But in all seriousness, I have three major takeaways for anyone else joining a company out of college.

What’s valued in school work is different than what’s valued in actual work, i.e. beauty is in the eye of the beholder.

As an engineering undergrad, my main objective—besides learning—was to submit projects on time. In the workplace, though, I’ve found that emphasis is heavily weighted towards design. Poorly designed code causes headaches and trouble down the road. Instead of focusing on simply getting the solutions working quickly and moving on to the next stage or problem, you have to think robustly about the end-to-end quality of your work and its future usage.

This has been challenging for me because good design—creating code that is flexible, scalable, reusable—was not a focus in school. My projects were graded on functionality, but at work my teammates evaluate code on how elegant the solutions are because functionality is the expected baseline. There may be a thousand ways to screw in a lightbulb, but only one of those ways is maximally efficient, uses the fewest number of resources and involves automating the process so you never have to manually screw in a lightbulb again.

Testing is another major portion of the development process that was largely absent in school. After I started at Enigma, I was thrown into a world of continuous integration and pull requests, where every bit of code I wrote went through a series of tests and peer reviews. I discovered, and eventually embraced, the concept of Test Driven Development, or how writing tests before you implement a feature or fix a bug is a great way to both document the code change you’re trying to make and keep track of whether or not you’ve accomplished the task. TDD helps keep code changes organized and prevents scope creep, and running our test suite catches so many bugs I’m unsure how I ever worked on projects without one.

Learning happens in a variety of ways—take advantage of the opportunities.

I’ve learned a lot about learning this year.

I’ve discovered that the practice of pair programming is one of the quickest ways to learn. When you concentrate on a problem with another developer, you get a glimpse into how they operate, allowing you to take the things they do well and apply them to your own process. You also gain insights into the code you would not have had otherwise and solve challenges you may not have been able to on your own. In other words, you become a better developer in a shorter period of time, like taking a shortcut in a video game. Pair programming has been one of the most rewarding experiences I’ve had at Enigma, as I have been fortunate enough to work with some incredibly generous mentors and teammates.

Not long after I started, I also realized that learning on the job wasn’t enough to improve and advance as a software engineer. I spoke with other junior engineers and new grads and discovered they had similar sentiments, which brought rise to a book club for learning design patterns (we covered Head First Design Patterns by O’Reilly). After several months of the book club, the idea snowballed into an organization we dubbed the Software Craftsmanship Guild. The purpose of the guild is to learn the software development skills you don’t necessarily have the time or opportunity to learn in your day-to-day, which encompasses how to write clean code, refactoring paradigms and of course design patterns. We’ve found that reading foundational software engineering texts and discussing the concepts we learn as a group—as well as jointly finding examples of the concepts applied—is a more motivating and fun way of learning the material than tackling it on our own.

Be ready to make mistakes, as well as make an impact.

Everyone’s first job is a little bit nerve-wracking—it’s like being thrown into water when you’re not certain you know how to swim. Starting out, I think I had unrealistic expectations for myself that I wasn’t sure I would be able to live up to. But after working for several weeks, experiencing some successes (i.e. completing tickets assigned to me) and navigating over some speed bumps, I came to understand my fears were unfounded.

One of the many benefits of working at a startup is you can see first-hand how your work affects the rest of the company. Seeing my impact has given me the confidence to overcome my fear of failure, which I’ve found to be beneficial to my learning; I’m more willing to take on tasks I’m not sure I can do, and those are always the ones that teach me the most.


In my past year at Enigma, I’ve done everything from help build the backend for an end-to-end data orchestration platform, produce a restaurant inspections data webapp in 5 short days, to co-found the aforementioned Software Craftsmanship Guild. I’m on a different team than when I started, with a new set of problems to solve and fresh learning opportunities. My work has continuously provided interesting challenges and a great sense of camaraderie, and I’m excited to see what comes next.





______________________________________________________________________________

Interested in taking on a challenging role and want to join the team? We’re hiring!