Title: Principal Product Software Engineer
Company: NodeSource
Languages and skills: C/C++, JavaScript, Node.js, Linux, Git.
Years of experience: 14 years of programming, 8 years with Node.js.
Contributions to the community: Core contributor to the Node.js project for 5 years. He stepped back in 2017 to focus on NodeSource product-related projects, but now he is back to contributing to Open Source. Recently he opened a pull request to libuv that you can find here.
Mentorship: Trevor has mentored other people when he was a core contributor to Node.js. Right now he hasn’t been mentoring as much, but is willing to do so. He will never refuse if somebody asks for help.
List of talks:
- High Performance JavaScript
- The Mad Science of Node
- You Did What? Understanding Node.js Optimizations
- State Of Node
- The Birth and Evolution of AsyncHooks
- Node.js Now Q & A
- Tracing the Event Loop with Asyncwrap
Favorite customer issue to solve: Many years ago, Netflix brought in Trevor as a consultant to help with performance issues they had with their website's A/B testing. Together they came up with a solution that outperformed the previous implementation in both throughput and resource usage. Part of the solution they developed was touched on briefly in a talk given by Alex Liu about scaling A/B testing.
Favorite personal project: Trevor is working on a Planetary Motion Simulation that you can find in this repo. The simulator is based on certain parameters (for example, the mass and the temperature of the sun) and will tell you stable orbits for planets. This project uses Node.js, native modules, and C++.
Favorite enterprise project: Trevor likes to work with Event Loop analysis in Node.js. His work has led him to a patch in Libuv for a new metric. The patch is intended to predict the state of an application using only Event Loop related metrics.
Least favorite kind of work: Fixing timing bugs that can’t be reliably reproduced.
Favorite song: Bassnectar - Reaching Out
Hobbies: Playing D&D with his kids, drawing, speed cubing and of course programming.
INTERVIEW:
What did you want to be when you were a kid?
Good question. I don’t know. When I was a kid, I remember wanting to beat Mario Bross :D .
laughs That's an interesting dream!
Yeah, when I was 7, I almost did it! Just to be interrupted by my brother, who turned off the console because he wanted to watch his program. Ever since I wanted to beat the game before I died. laughs
And did you?
Yes, a few weeks ago - 26 years later. I was finally able to do it and it was totally anti-climactic. laughs.
Ok, but in all seriousness: What did you want to be when you grew up?
I wanted to be Cyclops from the X-Men - Smirks more - but that's a dream I don’t think will ever be fulfilled except for many years in the future with the help of advanced technology - but for now, I will settle with being a Node.js developer.
Lol! Can you tell us about your journey from wanting to be Cyclops to becoming a Node.js developer then?
My life as a programmer started in school with three other nerdy friends who enjoyed programming. On the weekend, we carried our computer towers and massively heavy CRT monitors to each other’s houses to play Warcraft II. Of course, setting up our LAN in Windows 95 was no small feat. My first steps had the simple goal of automating away all that pain so my friends and I could get on with our gaming.
What’s your favorite Warcraft character?
My favorite was the human mage. Combining the invisibility and polymorph spell was totally overpowered :D
And what happened to those 4 guys, did they all become programmers?
Three became programmers (including myself) and one a technical document writer. Even though I threw my first lines of code on the weekend with my friends, my story with computers goes way back.
How so? Tell us more!
Ever since I was a kid computers have interested me.
My elementary school had computer courses starting in kindergarten. Even at five years old, sitting in front of a computer felt natural. My future as a programmer was pretty much sealed at that time.
During college, I wanted to try out different fields to ensure that there wasn't something that would be a better fit for my career. After switching between physics, mathematics, and a very short bout with business, I decided to embrace working with computers for the rest of my life.
After embracing my future as a programmer I realized that college wasn't going to help me. So I dropped out.
Interesting! Dropping out of college seems like a big decision. How did you know it was the right move?
My first programming class was learning C++. The teacher had been a professional programmer for years before he decided to start teaching. During the semester, he would explain how what we learned in class would be used in the workforce, and what we shouldn't be doing despite what the textbook said.
On the first day of the following semester, the professor told everyone to write a program using one of the aspects of the language that the previous semester's professor had told us never to use. At that moment, I realized what I needed wasn't a degree but experience. I dropped out that same week.
What happened next?
I got my first job as a Junior Database Administrator. A large part of the roll was handling issues that would pop up from the developer's code. From this, I quickly learned the importance of taking responsibility for my code and not expecting someone else to handle my laziness. Otherwise, it may cause them to quit.
In the end, I didn't stay there long. I noticed some decisions were being made that would adversely affect the product. When I brought up the future issues that would be faced by making those decisions, I was ignored. That roadblock made me consider how much of an impact I had at the company and helped me realized there wasn't anymore for me to learn in that position. So I decided to quit.
Dropping out of college, quitting your first job. How did it feel to make these brave choices?
There's no reason to stick around and suffer if I believe the situation won't work out. Since I had just started gaining experience, I felt that continuing with either of those situations would only harm my ability as a programmer. Fortunately, plenty of jobs cared more about experience and potential than if I had graduated from college.
So what happened after you quit your first job?
I worked for GSI, where I programmed websites for big companies like Ralph Lauren and Toys R Us. These companies would send us illustrations for how they wanted the website to look. They required a pixel-perfect match for all supported browsers, and we supported IE6 through 8 and Firefox. Those were dark times in web development.
In my spare time, I worked on my open source projects. Mozilla saw my work and reached out. I eventually ended up getting hired and working on their metrics team doing data visualizations.
Mozzilla! That’s pretty impressive
Yeah, it was fun. My work involved some Node.js which I really liked. There an opportunity to focus more and more on it. I had gotten a little burned out on frontend work. I wanted to try something new at that time and my manager was supportive of that direction . After a while, I continued to contribute to the project and ended up becoming Mozzilla’s official Node.js spokesperson.
Oh that’s how you ended up working with Node.js!
Yeah. It was around that time that Dan Shaw - co-founder of NodeSource - reached out to me to work for what was known then as the “Node Firm, (before it became NodeSource). I was hired to teach and consult. Once of the accounts was Netflix and I helped them with an architecture review. Then NodeSource was created and Dan convinced me to stay.
Since then NodeSource has gone through a few evolutions. I believe I am the last person remaining from the company’s founding team. This was rather exciting, especially at the beginning. I was only supposed to work on Node.js Core and I did that for a while. ButI stopped working on open source when I landed a patch in Node.js Core that burned me out. This patch was a big feature that ultimately led to the asynchronous local storage API feature that was recently released.
What is the best and most challenging thing about working with Open Source Software?
One of the best things about working in open source is that you get to work on what you find most interesting. It is easy to stay involved in open source because you can choose what you want to work on. But it's not always easy. Sometimes there are endless loops of conversations with other contributors on why something is done in a specific way. That can be exhausting. Dealing with different ideas and points of view can be more challenging than the technical aspect itself. I would say that the overhead of generating and maintaining collective consensus in a community that is limitless in size can be a big challenge.
So you stopped working in Open Source for a while?
Yes. I was asked by Joe McCann to start work on a new project that would improve predictive scaling. The basis of it was to predict the state of the application through observations of the event loop. That was the seed for a lot of the research resulting in what we now call the responsiveness metric. Recently, I opened a pull request in libuv to add a metrics API.
It partially exposes what is required to perform all the calculations necessary for the responsiveness metric. We're hoping to be able to reveal this in more detail in the near future. I believe it will become a game-changer in a world of worker thread support.
You mentioned burnout. How do you know when it is time to change focus?
Sometimes it is better to stop and work on something else, rather than risking burning yourself out. Recognizing that point is a matter of experience. Every project has motivating and challenging aspects to it.
What is the most satisfying thing you have worked on at NodeSource?
Probably my work on the responsiveness metric. I was allowed to dig in deep and research how event loops worked. During my research, I ran thousands of tests and was able to accumulate some surprising results. It will be even more satisfying when we the opportunity comes to unveil all this work.
Can you explain in simple terms what the Capacity Metric is?
The responsiveness metric predicts how soon the application will need to scale before reaching capacity. It takes into consideration many aspects other than just CPU. Now that Node supports worker threads, a process running at 300% CPU usage doesn't imply that it's in a critical state. Our old ways of scaling are no longer valid.
What’s your favorite personal project to work on?
My favorite personal project calculates orbital trajectories of fantasy star systems. The desire to write this came after reading many fantasy and sci-fi novels that ignore even basic repercussions of the worlds their writers create.
So I thought it would be cool to create a simulator to make predictions about these star systems. By putting in simple information (like how many planets are in the system, the size of the star or the target surface temperature of a planet) the simulator will calculate whether stable orbits can be maintained. Eventually, I plan for it to calculate differences in surface temperature during the planet's orbit.
It probably seems counter-intuitive to write a physics library for fantasy novels, but it's relaxing to work uninhibited on random projects like this.
What’s your favorite fantasy novel:
Thank you Trevor for this interview! It was great and we hope it can inspire other developers out there...
