Melissa Stone joined Puppet Labs as an intern in June 2013, and became a full-time employee in August. She graduated from Lewis & Clark College with two bachelor's degrees: computer science and psychology. Outside of work, Melissa enjoys backpacking, rock climbing and cycling. Melissa was one of the top milers on the Puppet Labs cycling team during the September Bike Commute Challenge.
On Comments and Readability
In school, there was a familiar relationship between students and teachers, so I wasn’t worried about writing code that looked pretty, or had logic that was particularly easy to follow. Learning how to code to a different level of expectation in the workplace has certainly been interesting.
For example, at the very end of my student days, one of my teachers tried to ramp up commenting and making code readable. He wanted us to add a comment at least every 10 or 15 lines. Up until then, I hadn’t heard that: As long as your code did what it was supposed to do, no one cared how readable it was. So, trying to implement this best practice, I started adding comments in the code I was writing.
I started working here at Puppet Labs, and to my surprise, people told me to remove my comments: All they did was repeat what the code already said. I am still learning where comments are helpful to the team — and in our open source products, to other people using and playing with the code — and where comments are really just redundant and messy.
I'm also learning that where I feel I need to add comments, it might be a sign I should take a closer look at the logic in my code. Professional code should be easy to follow and self-explanatory. You should add comments to explain your thinking only if you're doing something unusually complicated or particularly difficult to follow.
On Reading Other People’s Code
I was a TA for an introductory class in computer science, helping kids who had never programmed before. To help the students, I had to figure out the logic they were using to solve the problem. Often kids would write themselves into a corner with their code, and get confused about where and when their methods were getting called, or how exactly their variables were being manipulated. So I’d go in, step them through their code, and try to show them how to follow the logic of programming.
I have to do the same thing here for myself, but at a much higher level: I have to logic my way through it. It’s not like everything I’ve worked on is especially complicated, but people here code at a much more sophisticated level. Some of what I’ve worked on is simple and easy to check, and fairly contained. But other stuff has been difficult to figure out because it’s a huge piece of code that can affect so many different things.
I’m glad I got to learn how to dig my hands into other people’s code in school. It’s not something most students got to do, and it’s proved so important for me. It showed me that you can get comfortable with being confused, and figuring things out while you’re feeling uncertain. Whether or not you’re actually working with someone face-to-face or just trying to understand what they’ve written, if you just slow down and suppress your feelings of being overwhelmed, it’s worth dealing with the confusion. Stepping through someone else’s logic is fascinating, because everyone approaches a problem in their own way. Once you understand how they’ve done it, you’ve grown in your ability to solve your own problems.
Here’s a whole aspect of programming that I feel isn’t actually discussed in school. We wrote code, tested it manually (or maybe with tests the professor wrote), and then handed the raw code in.
The process of packaging up software, and how complex that can be on different platforms, was something entirely new to me when I came to Puppet Labs. That, and figuring out how to best test a packaged piece of software. I had no idea what a finished piece of software actually was, or all the different ways it could be finished, or how many different ways an error in that software could impact the entire system.
Now I’m making my living finishing software. Doing it professionally means creating a finished product, software that’s been tested throughout its development. And not only creating a finished product, but creating different formats of that finished product for different distributions (e.g. tar, gem, dmg, rpm, deb, pkg, etc.). I’ve discovered a plethora of different platforms and distributions that an enterprise company has to think about. I didn’t have to know about any of that in school, because I was learning theory, not practice. Having to package up our software for all those different platforms has forced me to learn a lot about the practical world of system administration.
On System Administration
I think a huge gap in the education system (or at least my own experience with it) is the lack of teaching about software management, how that plays into system management, and some of the more difficult problems of system administration.
When you’re in school, it feels like you have a general grasp on the whole computer thing. But once you start working in a professional environment, knowing some of the basics of internet protocol, package management and the basic differences between platforms is so useful. There is so much value in having some system administration knowledge; ultimately it helps you become a better programmer, but that is an element of computer science that seems to be overlooked in school.
On Learning in the Workplace
My experience as an intern was pretty unique. I started as an engineering intern for the Puppet Enterprise team, and was there for such a short time, I never even got a project to work on.
I was asked if I’d like to switch to release engineering, with a hint I’d have a better chance of getting a job. My internship project then shifted to learning how to be a release engineer. It was very different from school, where you have write a program that solves a very specific problem. It’s easy to figure out the tools you need to work your way through those contained problem spaces: which tools or algorithms will perform better and which will perform worse. It’s such a grand topic — “learn how to be a release engineer” — and people are very helpful, but it’s up to me to figure out which tools will be the best, or at least better than what we’re currently using.
Becoming a release engineer is so big that it’s hard to quantify how much progress I’ve made toward it. So I guess you could say one thing I’ve learned about being in the workplace is, you’re never finished. You are always going to be learning new things, moving forward, redefining what you are. And I’ve found I love that. No longer am I learning just for the sake of learning — I’m learning to help improve what we currently have, to help real people do their work better, and make their lives better, on a day-to-day basis, and that is a lot of fun.
Learn more about Puppet Labs