August 2015 marked the completion of my tenth year at Atomic Object. Inspired by Shawn Crowley’s recent post, Consultancies: The Smart First Job for Software Developers, I’m going to take a look back at the wide array of industries and technologies I’ve worked in while at Atomic. How might those 10 years have been different working for a non-consultancy, like a product company?
Project Overview
I pulled some data from our time tracking system to find the five customers I’ve worked with most. For each customer, I’ll note the industry, the technologies I used, and how much time I spent working for them. The time calculation won’t be exact since I’m going off hours billed to the customer, but it will give a rough idea of how long I worked with them. (I’m using a 173-hour work month to calculate the number of months worked for each customer.)
| Project | Customer Industry | Team Size | Length | Technologies |
|---|---|---|---|---|
| Web Application | Supply Chain Improvement Consulting | 2 devs, 1 part-time designer | 22.4 months | Ruby (Rails), Javascript (jQuery), HTML (Haml), CSS (SCSS) |
| Multiple Custom Servers, Windows Desktop App, Mac OS X Desktop App | Furniture | 2-4 devs, 1 part-time designer | 11.2 months | JRuby, C#, Objective-C, C++ |
| Web Application | Insurance | 2 devs | 10.5 months | Java, JRuby (Rails), Perl, JavaScript (jQuery), HTML (Haml), CSS (SCSS) |
| Web Application | Retirement Community | 2-3 devs | 10.4 months | Ruby (Rails), JavaScript (jQuery), HTML (Haml), CSS (SCSS) |
| iOS app, Android app, Cloud API | Medical Instruments and Supplies | 2-3 devs | 9.2 months | Objective-C, Java, Ruby (Rails) |
All together, I put in a bit over five years of billable work for those five customers.
The next five biggest projects ranged from nine months down to six months, totaling another three years of billable work in the following industries:
- Web-Based Game
- Fitness Tracking, Mobile, Technology
- Financial Institution
- Automotive
- Software Product: Laboratory Information Management System
Finally, I’ve also worked on a number of smaller projects, most in the three- to six-month range.
Project Length
The majority of the projects I’ve worked on at Atomic have taken from six months to a year, with some outliers on either side. In a non-consultancy, individual “projects” likely average out to be in the same vicinity, mostly because it makes sense to break down work into manageable chunks. The biggest difference is in how we define a new project.
At a consultancy, a new project usually means a different customer or product owner, a different industry, different teammates, and possibly a different programming language (or set of languages). Elsewhere, a new project may mean continuing to work on the same codebase that you were working on in the previous project—most likely still using the same programming languages, the same teammates, and the same customer or product owner.
One downside to switching projects frequently is that it’s difficult to get to the same level of expertise in six to twelve months that you can when you’re working in the same language and tech stack for years on end. But in my experience, a good developer can move well beyond basic competency in a few months, becoming an expert by the end of a year. It’s not the same kind of expertise that comes from many years of work and study, but it results in a very capable developer nonetheless.
Legacy vs. Greenfield
Four of my five biggest projects were all greenfield projects, with the other categorized as a legacy to me, but a greenfield project when Atomic Object began it. I think this would be pretty uncommon in most non-consultancy software development positions.
Even when a project is greenfield at kickoff, once it gets to the production stage, it will need additional features and other support over time. These recurring projects give Atomic developers the opportunity to work in a legacy codebase—something that’s crucial for professional development as it’s the best way to build up an understanding of which coding patterns and practices can cause pain down the road. Plus, you really learn the benefit of an automated system test suite when you have to make changes to someone else’s code.
That being said, working unfettered in a new codebase is always more fun.
Technology Choices
I’d guess that the Atomic team has total control over the programming languages, frameworks, and libraries we use roughly 50% of the time. And in those cases where the customer has specific technology requirements, most of the time it’s something that Atomic developers would have chosen given the chance (e.g. the customer wants a Ruby on Rails web application).
Again, I think this is pretty uncommon at a non-consultancy. Introducing a new library, framework, or programming language can be a very difficult task in many software development teams.
Team Makeup
At Atomic, I’ve worked on teams varying in size from the occasional solo project up to teams of eight developers, with the most common being a two- or three- developer team. But in all the time I’ve been here, I don’t think I’ve ever worked on back-to-back projects with exactly the same developers. What’s great about that is the ongoing opportunity for cross-pollination of ideas and practices from developer to developer.
From what I’ve seen outside of Atomic, most software developers don’t work as closely with their teammates as we do at Atomic, favoring separate cubes or offices and less pair programming than we use. It’s also far more common to work with the same set of people for much longer periods of time, regardless of the overall size of the development team.
Also, based on my experience, a software consultancy is not a good place to get experience working on really large products, since team sizes tend to range from the dozens to hundreds of developers. But I’m not sure that’s really a bad thing.
Customer/Product Owner
When you work for a software consultancy, your customer/product owner is your boss. Changing bosses just about every year exposes you to a much wider array of business people than working for the same middle manager year after year. I’ve personally worked for customers ranging from CEOs of public companies to startup founders and corporate project managers.
Looking Back and Looking Forward
Looking back at my 10 years in a software consultancy, it seems that the thing I’ve enjoyed the most is the frequent change. The next project brings a new customer, a new industry, new teammates, new technologies, and best of all, new challenges.
I find this interesting because when left to my own devices, I tend to avoid change. Change pushes me out of my comfort zone. But always being in your comfort zone can get boring over time.
For someone like me, working at Atomic Object brings just the right amount of forced change, along with the comfort of continuing to work in a great office with a wonderful group of friends and colleagues.
I’m looking forward to finding out what the next 10 years will bring.