A Day In The Life of an Engineer at Pivotal Labs
Micah Young
ENGINEERING MANAGER, PIVOTAL LABS, NEW YORK
I found Pivotal Labs… through another developer in NYC who recommended the company to me. I had been an independent Rails developer for a while. I felt like I wasn’t learning a lot and like I was at the whim of whoever was able to sit with me and teach me something. I wanted to go to a place where I could really level up my skills and learn the right way to build software, not just read Stack Overflow suggestions for how to do things.
I decided to join Pivotal Labs because… I wanted to get into consulting. I found myself getting tired of working on the same product. I felt like I was surrounded by like minded people as soon as I stepped in the door — people who like to build high quality software, talk about the best ways to do it, and who have a sense of humor and self awareness. Something that I didn’t see anywhere else is the explicit focus on constant improvement. It’s built into the process.
I am currently working on… Single Stop, which is a nation wide application for people in need of financial or social services. The app lets the user find and apply for government benefits and get face to face support if they need it. It’s a Ruby on Rails web app, using Slim as a template engine and Sass with Bourbon for CSS. The app is hosted in the cloud and we use RubyMine IDE in our development environment.
9 AM
PROGRESS REVIEW
Our project for Single Stop is a screening tool to allow people in need to find out if they are eligible for government benefits. The tool also helps people find service providers in their area.
Our client developer Hector and I are reviewing the progress we made yesterday. We’re going to put together a plan for today so that we have an idea of what we need to discuss in team standup at 9.15 and if there are any blockers in our way.
Both of our client developers are new to Rails. They come from a .NET background and are familiar with MVC. To provide a better environment for learning we keep things simple and follow Rails best practices. This approach also facilitates project hand-off at the end of the engagement.
10 AM
SOLUTION PROTOTYPE
I’m pairing with Hector, our client developer. He is relatively new to the team. Right now we are talking through a tough business logic problem together to figure out what the simplest solution to it is. In a situation like this it’s invaluable to be working directly with a client developer who knows the business logic well and combining that with our general knowledge as Pivots to come up with a solution that makes sense. Since our client developer will be owning this project in the long term, we want to make sure that any decisions we come to he is comfortable with and believes in.
What we do first is that we break down the problem in the story into a set of tasks. Then we go through the code and mock out what we think will solve the problem. It’s a first stab and not the code we want to live with. We are just creating an initial prototype of the solution. When it starts to feel right we drop what we have and rewrite it — tests-first — and come up with a better implementation. We don’t always spike out a prototype first. Sometimes we know exactly what we want to do and jump into the first test.
This forces me to understand the problem and learn about what is really going on on a technical level. By making sure it won’t be my own code but that it will be shared with someone else, you get over the embarrassment of putting something out there because you know that someone else will review it. It also forces you to clean it up before you commit it. That’s where we rely on tests and it helps us end up with clean code.
11 AM
PUSH TO GREEN
We knocked out the first part of our story. Now we’re finishing the second part of it so that we can deliver it.
We have a continuous integration server (CI) that runs the complete test suite every time we push. After each successful build, CI will trigger a deployment to our acceptance environment, where the project Product Manager can test and accept the work we’ve done.
It took us a few iterations to get this running smoothly, experimenting on different tools to make sure this process is reliable. We iterated until we got to a point where it was mature enough and did not demand attention from developers so we can focus on working on stories.
12 PM
ONE-ON-ONE LUNCH
I’m heading out to a one-on-one lunch with one of my reports. I’m an engineering manager which means that I am a normal developer on the floor and a professional mentor to other developers. As engineers, most of our time is spent pairing and talking to people on our project teams. We take advantage of lunch time to talk with the people we mentor and don’t work with on a day to day basis. We usually grab lunch once a month to go through the person’s recent peer feedback and their professional goals. A big part of helping someone achieve their goals is to identify blockers, help them set up feedback loops with team members and track progress. If there’s something the developer can’t solve themselves, that’s where I can come in and help. I can provide a second opinion and help them work through it, whether it’s a project challenge, an interpersonal challenge, or even getting Pivotal Labs to try something new we haven’t tried before.
Feedback is essential on all levels for what we do. We try to get regular feedback that is specific, actionable and kind as much as we can in person. To get feedback spanning longer periods of time or to track progress over time, we use a feedback tool that we have developed ourselves. Pivots can also request feedback from their colleagues through the tool.
1 PM
REFACTOR
We’re adding a new screen to the app today. It introduces some changes to one of our main user flows. These changes made us rethink how we did the architecture for the flow leading up to it. We got our first integration test to pass, and now we’re documenting the user flow in our tests, as it exists now. We did some refactoring to make the code we are about to write fit better with our current architectural patterns.
2 PM
PAIRING
There’s always this uncomfortable moment in pairing when you have to take the mouse or the keyboard away from someone else. You either have to say “Hey, can I take over for a second?” or talk about line numbers on the screen. The best way to do it is to just point on the screen but that doesn’t work with two screens. That’s why we’ve developed a tool for it. We’ve hooked up a Leap Motion motion tracker with the shortcuts app.
If I am training someone else on tools or on good development practices, it’s best if they do most of the legwork. By using a tool like this, I can avoid interrupting them all the time and I can communicate the minimum amount of information required so that they can do the rest.
3 PM
REFACTOR
We got to delete a lot of the code and it felt great. We thought about it a lot before and then spent 20 minutes looking at how our refactor would affect the rest of the application. We have lots of confidence that we are deleting the right code and it ended up being a relief once we took it out.
4 PM
PASSING TESTS
We are finally adding more stuff to our integration test. It’s the finer details of the new user flow. On the left side is the app in its current state. This is the minimum that made our tests pass and we got it all done today. On the right is the final design for the app which is the goal we are working towards.
We have a good feedback loop from product and design. Linda, our designer, sits with us which makes it really easy to collaborate. A lot of the design has been done already and is available to us in our live style guide which has all the markup and styles. All we have to do is to bring in the styles from the guide and it just works.
I’ve learned a lot about getting more results with less code today. By having a real world use case, we got some validation that the software we use is flexible. I really feel like we have been doing the right thing. A pretty big architecture change only took us a few hours. Our tests are passing so we have created a pretty good process. All of this is from a story we hashed out pretty recently. We are able to go and implement these stories on Monday and now we are picking up a story with a big tech change.
5 PM
DESIGN PROGRESS
We have finally started to pull in completed designs. The app looks a bit fancier now. Since we already had our passing tests, there’s nothing more to do here code wise. We just want to avoid breaking anything we already have in here.
We realized something that made our refactor even better. We had different styles from what we had coded up a while ago from what we have now. Because of how we have separated up our codebase it makes it easier to use the new style.
6 PM
END OF DAY RETRO
We’re wrapping up the story for the day. We try to leave ourselves a good failing test so that when we come back tomorrow we know exactly what to do next.
By being able to leave at 6 pm each day we can plan ahead for the end of the day. Hector and I do a mini pair retro at the end of each day. We talk about what went well today and what was difficult that we should try to change tomorrow. We’ll look back at the exact same retro items we did yesterday to see if we fixed what we said we’ll fix. This is especially useful when you work with another developer for the first time. The other person may not yet be comfortable telling me not to do things that they find annoying. This way we can surface issues quickly and solve them constructively together.
Pivotal Labs is an agile software consultancy. We collaboratively build and design mobile and web apps for the world’s largest brands.
If you’d like to learn more, please visit our careers page.
This profile of Micah Young was edited by Joanna Beltowska.
Follow us on Twitter
Visit our careers page
A Day in the life of a Pivotal Labs Engineer was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
About the Author
