The first two weeks of my apprenticeship at MX were like getting in a car that I'd never been in before. The last two months have been like someone pushed the 'little red button.' Ever seen Men in Black?
Let's talk about what it's like to work at MX.
I'm sure you're thinking "In your first post you said the pace was slow. What gives, Cam?"
Well, in the beginning we were given small, specific tasks as an introduction to the codebase so we wouldn't get overwhelmed. Now that we've had much more exposure to the codebase, the deploy process, and feature addition, it feels a lot like having a rocket strapped to your back.
The MX engineering team deploys to each service multiple times a day, and there are so many internal repositories that keeping track of every comment and issue is virtually impossible. The scope of the issues and features being added to the platform is so broad that it's impossible to keep track of how everything is moving, even from 10,000 feet. This is the largest engineering team I've ever worked on, though, so it may be that the immense scale I'm noticing is just from the size of the staff.
The dynamic of the work between the apprentices has also changed significantly. It used to be that we all wanted to work on the same projects or be involved with the same problem. Now, we're discovering that there are enough interesting things to work on that we can all work on different parts of the platform and still find something we're interested in.
The group projects have gotten less frequent as we shift more towards working with the other engineers. We're still aware of the projects that each other is working on, and we still share the knowledge we gain through the projects we work on however we can, but it's less of a mob mentality now and more of a 'what can I find that interests me?' thought train.
My Own Knowledge
If you were to compare two-months-ago Cam to current-day Cam when it comes to development skill, current-day me could run circles around my former self.
The learning that I've had at MX has been unparalleled to any other education experience in my career. MX has such unique problems they're solving and such talented engineers to do it with that gleaning knowledge from day to day is easy as long as you're paying attention.
If you ask someone to explain something, they will. If you want to learn more about something, someone who knows more will come and help you out. If you want to jump in on a problem or feature that someone is working on, you're typically welcome to. The culture here is one of learning, and for someone who's looking to become the best engineer they can (like myself), it's a great place to be.
Working With Our Mentors
In the beginning, working with our mentors was a lot of "How does the platform work?" and "Can you tell us about how this system works?" Now it's evolved into a lot of pair programming, asking more information about a bug that we grabbed all by ourselves, and only the occasional "How does this system work?"
I still use my mentor's skill as my first escalation point, but only after I've tried to dig out what the system is doing.
Surprises Along the Way
There have been some interesting problems that I've run into that I wouldn't have even thought about anywhere else, especially in my own small, personal projects.
With Great Scale Comes Great Responsibility
The code that's in the main path of the typical user at MX is also in the path of millions of other users. So when we code something, we code it to be fast. When you're working on something, you have to consder what makes it the fastest and safest. One method might be faster than another in a certain interpreter or any number of other things that the engineers here have run into. The great thing is, the engineers will help teach you whysome practices are better than others. That's been great for helping the apprentices level-up our development skill.
Working with a team this large, you develop a number of other skills that you wouldn't think about unless you had some time to reflect on said skills (like in a blog post, maybe?). Working with other engineers in a team this large means that you have to learn how to present your ideas and feedback in a constructive way. Phrases like "I don't like how this works" and "This shouldn't go here" don't work well in a team like this all by themselves. When giving feedback, you should also provide a point that the author of a commit can improve on. "I don't think this will be the fastest code, have you tried something like..." would be much better received by all.
There's a number of other skills that you wouldn't think of that you develop just by seeing other engineers do it in action. Working with the product team, speccing out a feature so it doesn't cause or require any downtime, learning a new shortcut on your favorite text editor, and getting the smallest cuts of a project up and out so you have something that works and can build upon are just some of the things that have come up working at MX so far.
Wrapping Up The Day
Day-to-day, it actually has come to feel like the apprentices are part of the actual engineering staff, and many engineers will tell you it feels like that for them too. We show up, participate in our daily standup meeting with what we've been working on or plan to work on for the day, then we go to it and use whatever resources we need to get that done. We pair with other engineers who are working on the same projects we are, we get asked questions about some of the functionality we've built in the past couple months, and we constantly look for the things to work on that will provide the most value, just like everyone else here. The learning that we've all gotten has been absolutely invaluable and every day is full of new experiences and knowledge, working on a great product with a great team. It's absolutely amazing at MX.
By: Cameron Kidman, Engineering Apprentice