The first time I heard about Atomic Object, I was back home in Iran. I was browsing a Pry gem webpage to see if I could find a substitution for my good old debugger gem. I saw the name “Atomic Object” on the gem’s sponsor list. I thought to myself “hmm — cool name! Atomic Object”.
Later, after moving to the United States to pursue my Masters in Computer Science at Grand Valley State University, I heard about AO lots of times. The company was famous among faculty members for promoting a unique culture and sticking to Agile principles. They had a good reputation in the Agile world as well.
Back home, I worked in a semi-agile team, developing geographical web-based information systems with Ruby on Rails. We had a fair amount of integration tests, using Cucumber as the end-to-end solution for testing, but we never used Test Driven Development to drive our design.
I was always interested in Agile methodologies; I studied cutting edge books and blogs on the topic, and I was passionate about implementing these great ideas in my workplace. The company that I was working with was open, to some extent, to adapt new things, but that wasn’t enough for me. I wanted to experience a professional environment that truly practiced the values and principles I read about in the books. I wanted to start the process of becoming a software artisan.
To be in a workplace genuinely devoted to craftsmanship, I started to apply for internship positions for the summer of 2014. My interview with Facebook didn’t turn into a real job and, finally, I was offered an internship seat at AO. I started my internship in early May.
From the very first stand-up meeting, I saw that communication is a key factor at AO. The first day, I paired up with my mentor, Will. He was a real asset and helped me in the process of getting accustomed to the new environment. The emphasis on Pair Programming at AO helped to keep me up to speed on the project. Before working at AO, I was used to writing tests after implementation; I never did a real project using Test Driven Development. I always used TDD for small programing Katas and exercises; using it in the enterprise world on a commercial project was a whole different story. Pairing with my team members (Will and Chris) helped me to quickly absorb the thought process required in driving software design using tests.
On a recent RubyRogues podcast episode, Dave Thomas said something really interesting:
You are being agile if you follow a process that says, “Where am I now? Where do I want to be?” Take a small step towards it. Analyze what happened. Go back and do it again. That’s agility. And there really is nothing else to it but that. You apply that fractally. So, you apply it to variable naming. You apply it to coming up with a release schedule, whatever it might be. And you do that over and over and over again, and you’ll be successful.”
Dave’s statement clearly describes the concept of agility in Atomic. AO adapts agility. There is no cumbersome unrequired ‘Agile’ process forced on teams. Teams adjust to what works best for them. This is really valuable and helps the team to keep pace with their customers.
At Atomic, I work on billable projects, and I am involved in technical decisions. I am not just an apprentice working on small side projects, but a part of a real team. This makes the whole process more pleasant for me. This feeling of self-satisfaction drives me forward and makes me even more passionate about my profession.
People give a shit about their work at AO. All the people I interacted with love their jobs. They are passionate about their work, and they want to build great products; concisely they want to be the best in their jobs. They are committed to their everyday tasks, and they embrace the interaction with the customers. Most people work on personal projects on the side. These learning activities keep them up-to-speed in the fast-changing software development loop.
Interaction with Customers
Customers are an inseparable part of teams at AO. During my three-month internship, I was involved in lots of interactions with our customers. Both sides see one another as a strong point to rely on to deliver an exceptional product. Feedback, acquired from customers, is considered while working on jobs. It drives the development team to improve their process and workflow.
People at AO are generalists. As far as I know, there is no person pre-assigned to a specific type of project; for example there is no one allocated to Ruby On Rails, Ember, iOS or embedded systems projects. At different times, Atoms can revolve around different types of projects. The essential factor in AO is the ability to learn and adapt. By sticking to the rule of having generalists, Atomic can guarantee that projects aren’t dependent on a limited number of specialists.
To be honest, at first I was a little disappointed that I didn’t land a spot with a bigger company; but this feeling disappeared in the first two weeks of my internship, as I started to interact with more people and found new friends. Besides, I learned a great deal during these three months.
I took an internship at a small company and learned what it means to put Agile into practice in a flexible and effective way. This was a great experience for me, and I’m very happy that I was given the opportunity to be part of a bigger family, a family of Atoms.