Rice University Computer Science alumnus Jarred Payne (B.S. ’12) is a senior software engineer at PROS. The role requires Payne to pay keen attention to specifications and to ferret out details about what their customers are trying to achieve. Recently, he’s been part of a team creating Docker images that allow PROS customers quick and easy access to data structures stored in the cloud.
“My team specializes in microservices. Think of them as parts of a car – a series of connected parts that have a defined way of working together, but aren’t tightly coupled to each other. For example, when you get a flat tire, you don’t need to go and replace the whole car, you can simply replace that flat tire with a new one. You don’t even need the same brand or type of tire as the previous one as long as it fits certain specifications defined for your car,” said Payne.
Payne said microservices rely on virtualization tools, but virtual machines (VMs) proved too cumbersome because each required its own operating system (OS) on top of the physical host’s OS. His team at PROS uses Docker, a virtual environment that allows several containers to share a single host OS.
“Docker is an improvement in virtual environments because its containers don’t require the space for an operating system. Multiple container images can share the host OS across the Docker platform, making each image lightweight.
“In fact Docker works well with traditional VM’s in that you can deploy several Docker containers on a single VM. We make Docker containers of our microservices and use technologies like Kubernetes and Mesos to deploy and scale them in the cloud. This allows the development team to achieve continuous delivery and scale to our customers’ requests.”
Creating these specialized microservices is only the first challenge for Payne’s team. Their platform is part of a service level agreement (SLA) that requires a rapid response time. When a client requests data from one of our microservices , the results must be delivered back to the user through the image within milliseconds.Payne talked about the sense of success his team feels when rolling out a new set of services and images under a challenging SLA.
“Under one client’s SLA, we had to meet 99.5% of the calls with less than a second response time. While we were still in development, we were at 7 seconds. We were all working on our different tasks, but everyone was also monitoring the response time metrics on the wall displays. We could see the line dropping a little at a time, sometimes dipping then going back up.
“Finally, there was this day that we managed to hit a sub-second response time and stay there. Everyone noticed it at the same time and you could almost hear a sigh of relief across the room. It took a lot of work to get to that point, and to see it pay off was really great.”
He is passionate about meeting his team’s SLAs and spinning up custom Docker images of their microservices, and he’s discovered he can consistently deliver his best work through 90 minute sprints. After working for an hour and a half, he takes a break – maybe checks email, joins the weekly scrum, or walks to the park next door. Then he’s ready for another 90 minute sprint.
PROS senior software engineer Jarred Payne takes a break, often walking in a local park, between sprints.
Pushing back from the lines of code forces his brain to take a break from the details. Coming back to his computer with a fresh mind helps him reconsider the bigger picture and – like he learned in COMP 410 at Rice– to think before he codes.
He also carves out a long lunch hour once a week to play board games with his colleagues at PROS.
“The games change from time to time, but Wednesday is board game lunch. We take an hour and a half and just play a game. It’s a great way to completely clear my mind. Then when I go back to my first afternoon sprint, I’m recharged and ready to focus.”
His advice to current CS students is to look for research opportunities as freshmen and sophomores. “Go to your professors and see what they are working on and find out if there’s a chance to work with them,” he said.
“That was really useful for me. I worked with Professor Sarkar and learned more about parallel programming. Working with your professors on research also gives you a personal connection, which is helpful later on when you need letters of recommendation.”
Payne had arrived as a Computer Science major as the department’s curriculum began to change. He said his classes had a mix of the old curriculum and the new, and he enjoyed both styles of courses as well as the excitement of being part of the first cohort to complete assignments in the new material.
“Ballworld was really cool. That was part of COMP 310 with Dr. Wong; it was the first time he’d used that project in a class. In COMP 410, another great Wong course, we actually failed our class project. All of us had invested a lot of time, a lot of effort, and a whole lot of pain — and we all crashed.
Learning to think before you code
“It was a hard fail,” said Payne. “We spent a lot of time exploring a bunch of different ways to accomplish the solution and none of them worked. I’d never failed at something that hard. The whole class was surprised. We learned there are some problems you just can’t solve alone. Our failure to collaborate led to a failure to solve the problem.”
But that class also gave the students excellent stories for their interviews. Payne said recruiters frequently ask about applicants’ most challenging projects and how they could have been solved differently. The failed COMP 410 project and the dissection of the failure at the end of the semester provided strong examples for each student in the class.
“The biggest take-away from COMP 410 was ‘think before you code’. We unfortunately jumped straight into the coding,” he said. “We didn’t really talk to our customer that much to find out what they wanted. We should have taken a step back, asked more questions and clarified things that were ambiguous.
“When you jump in and code first, you will get to a point where you are stuck. No amount of coding will fix a bad plan. You have to spend time with your design and learning to understand your specifications before you get to the coding. So yes, when recruiters asked us, we could say exactly why we failed and what we should have done differently.”