Getting called up to the Majors

LoneStarRuby Conf 2013

Reid Gillette

1 talk

Getting called up to the Majors

by Reid Gillette

In the video "Getting called up to the Majors," Reid Gillette shares his journey from an amateur web developer to a professional Software Engineer at Mavenlink, a startup in San Francisco. He discusses the significant transition from developing small, personal projects to working on a large, complex Rails application alongside a skilled team. Throughout the talk, Gillette highlights the importance of mentorship, collaboration, and continuous learning in a developer's career.

Key points discussed include:

Finding Mentors: Gillette shares his experiences with mentors like Felix, who introduced him to Ruby on Rails, and Chris, a colleague with a different background. He emphasizes the value of surrounding oneself with experienced developers for support and encouragement.
Company Culture and Pair Programming: At Mavenlink, a culture of pair programming is pivotal to their workflow. Gillette outlines how pairing allows junior developers to learn alongside seniors, helping bridge knowledge gaps and facilitating skill development.
Adapting to New Environments: Gillette discusses his first month at Mavenlink, where he felt out of place but learned to adjust his coding style to align with his new team's practices, emphasizing the importance of adaptability in a junior developer's role.
Constructive Feedback and Learning Methods: He describes the 'ping-pong pairing' technique, where developers alternate roles, promoting active engagement and deeper understanding. He also advises juniors to ask questions and not hesitate to take the lead during pairing sessions, which fosters confidence and growth.
Selective Hiring of Junior Developers: The selection criteria for junior developers should focus on passion and a genuine desire to learn, rather than just seeking financial rewards. Gillette believes that identifying candidates with a strong interest in engineering leads to better team dynamics.

In conclusion, Reid Gillette stresses the significance of mentorship, collaborative work environments, and continuous learning as key drivers for success in the software development field. He encourages junior developers to seek mentors, engage in pair programming, and actively participate in their learning journey while emphasizing the need for supportive and flexible company cultures. His own journey exemplifies the opportunities that arise when one is willing to learn and grow within a community.

00:00:15.440 Uh, before I get started, my name is Reid Gillette, and I wanted to share my story about how I ended up being a professional web developer, which I've been for the last year. Before we get too far along, just to get an idea of what kind of audience I have, how many people here would describe themselves as junior developers, meaning people who aren’t doing this professionally? Good, good! Welcome! Because I don’t know if you know this, but I was here two years ago and felt like an interloper, or that I was sneaking around among people who were supposed to be here. But I hope by now you've figured out that you are supposed to be here. This is where you're supposed to be, and good for you for being here. That’s an important step.

00:01:11.280 And just out of curiosity, where are the more senior people, perhaps the ones who are supervising? A couple of them too? Good, good, welcome, everybody.

00:01:24.560 So I started putting this talk together, and as I thought about all the different things I wanted to share, I realized there was a common thread connecting everything. It all came back to the people I met, the people I was interacting with, and the people who encouraged me. I wanted to introduce you to a couple of those people. The first one is Felix. Despite his photo, he's actually a really generous and nice guy. I was friends with Felix before I got into development; I was just happily designing retaining walls along highways, none the wiser. After fiddling around with some PHP, which was what I had worked on before, I started writing a web app that was database-backed, which turned out to be quite a nightmare. I didn’t know frameworks or anything, so I was essentially writing this ORM by hand in PHP, and it was really horrible.

00:03:05.760 One day, I happened to mention to Felix that I was doing this, and he said, 'You’ve got to check out Ruby on Rails.' I was skeptical at first, but then I got the "Agile Web Development with Rails" book like many people here may have and started developing with it. As I did, I had this resource in Felix; I could go to him and say, 'Hey, I'm running into this problem,' or 'Here’s the interaction I'm trying to create, what do you think?' He was an amazing sounding board. We never actually paired together; I’m honestly not even sure he’s ever seen any code that I’ve written. However, we did a lot of whiteboarding and discussing various technologies, and he encouraged me to come to LoneStar two years ago, which was incredibly valuable.

00:03:33.240 About a year ago, he and I went to RailsConf here in Austin, and that’s when I met Andrew, who is the Vice President of Mavenlink. I interviewed with him, and we seemed to hit it off. He understood my passion for what I was doing, and I learned a lot about Mavenlink: about pairing, their stack, and what they could offer. During an informal conversation, Andrew asked, 'Would you be interested in moving to San Francisco?' I had come to RailsConf without any expectation of looking for a job; I said I was going to look for a job, but I never thought I would actually go out and look. Suddenly, someone was asking if I would be interested in moving to San Francisco.

00:04:15.840 I thought about it for a while and decided, 'Yeah, actually, I would be interested in moving to San Francisco.' I accepted the offer, and there was about a three-week period between accepting it and moving out. During that time, I sold everything I owned and moved to San Francisco with two duffel bags, staying in a hotel room for two weeks. It was an intense experience, and I don't know if I could do it again, but it turned out really great. Working at Mavenlink, I met another person, Chris. He didn't give me a picture, so I get to use a grumpy cat picture instead.

00:05:04.479 Chris had been with Mavenlink for about six months when I joined. He’s not a web developer; he does web development now but wouldn’t describe himself as one and doesn’t really like it. He has a background in game programming and had worked at a big enterprise corporation, Kaiser, telling amazing stories about working in such a huge system. People often discard someone like Chris because he doesn’t like Ruby or Rails and is vocal about it. However, I took that as an opportunity because he’s still been a significant resource in my development progression. It’s valuable to have someone who can express what they don’t like about Ruby and point out things that are weird about it. Because of that interaction, I've learned some Python since Chris really likes it, and we go back and forth discussing our preferences.

00:06:45.040 These people were incredibly important to my growth as a developer, and it wasn't just Felix and Chris; I’ve met a lot of people in the industry. We even have a guy who's only 19 years old. He graduated high school, married his high school girlfriend, and moved to San Francisco, just like I did—he works at Mavenlink and is one of our best developers. Even though he’s ten years younger than me, I learn so much from him, so the takeaway is: junior developers, you guys need to find these people and surround yourselves with them. Like Chris has been for me, they may not be who you initially think they are—but they are all around you.

00:07:30.319 I have good news for you: by coming here, you've already found many of them. These are the types of people you want to be around. For those of you who are senior developers, be this person. Felix was a mentor to me in a way, but the others—Chris and those younger developers—didn't seek to mentor me; they were not highly invested in my success. However, the amount of interest they took in me encouraged me, and that small amount of encouragement was worth volumes. I hope everyone is involved in Ruby user groups or attending conferences because you can make a significant difference with very little effort.

00:08:30.480 Mavenlink chose to focus on pairing for a couple of reasons. The thing that stood out to me was that they did 100% pairing and bootstrapped their engineering practices at Pivotal Labs. I’m sure many of you have heard about Pivotal. Their philosophy on pairing ranges between everyone soloing and everyone pairing all the time; they emphasize that more pairing is generally better than less. Rather than trying to categorize each case, they advocate for always pairing. That greatly simplifies their overall philosophy. What was encouraging during the interviews was hearing their engineers discuss pairing. I asked them how they felt about it, how they thought it worked, and I was pleased to hear that they acknowledged pairing isn’t a silver bullet and doesn’t solve every problem, but it’s a fundamental part of how they operate—it’s not dogma.

00:09:34.560 This gives me comfort that many of their practices aren’t rigid; they are interested in being flexible and willing to change what doesn’t work, which was important to me. The codebase at Mavenlink presented another interesting point: when I joined, they had just upgraded to Rails 3.2. This app started before Rails 2.3, and maintaining that legacy required substantial engineering effort. As a junior developer, it made me feel comfortable that I could read existing code and contribute immediately without a massive learning curve. I had experience with Rails 2.3, which was similar to their current dev stack. We used RubyMine, which I hadn’t used before, but generally, with MySQL, it was pretty standard for a Rails stack.

00:10:48.880 It was crucial for me to feel comfortable, especially because, as I mentioned at my first LoneStar, I felt like an interloper, like I had tricked them into hiring me. But I know that wasn’t the case now, and expressing my doubts during the interview process was critical. I was upfront and very vocal about gaps in my skills and what I'd like to learn. I conveyed this to them, which allowed me to feel confident that they hired me knowing these things. This also showed my passion, and I was working towards filling those gaps.

00:11:29.280 Much like I mentioned earlier, I didn't do a lot of JavaScript when I first joined; but by 2013, during my six-month performance review, I expressed my desire to improve my JavaScript skills. They agreed and let me work on Backbone, which significantly helped me grow in that area. It’s been rewarding to work for a company that recognizes my weaknesses and puts me in a position where I can improve and succeed. It’s through conversations with people like Chris that I’ve learned; he has been a great resource where I could ask questions freely without feeling intimidated.

00:12:38.960 Regarding pairing: it has been absolutely critical in my growth. We actually have a fairly junior team at Mavenlink. I don’t know if Alec is here now, but he was also hired as a junior developer, and we’re developing a good training program. There are basically two ways we pair: sometimes it’s junior-junior, which works well for certain bug fixes. However, it can often become the blind leading the blind. I feel the best pairing is when a junior developer is paired with a senior developer.

00:13:41.440 This method does have a downside: you can fatigue the senior developer involved in the pairing quickly. However, it effectively matches strengths and weaknesses. For instance, Chris did not know Rails as well when I started, but even though he was a much better developer than I was, I had more Rails experience from my own projects. This dynamic between us worked well; Chris understood the codebase better and what techniques to use, and I could get things done in Rails, creating a great learning opportunity for both of us.

00:14:47.680 We recently worked on a project using a methodology we humorously called "extreme pairing"; in reality, it involved two people working on separate parts of the project while frequently discussing how those components will interface with each other. I was working with Rails while Chris was working on the frontend in Backbone. During this collaboration, he would ask for certain data endpoints, and it was simple for me to create a controller action to provide the necessary data. This collaborative approach mimicked how our respective software would interact in a very practical way, which was productive for both of us.

00:15:55.679 More recently, I’ve had a chance to work alongside Chris as my role evolved, given that I've been there for a year. I still see how valuable pairing is, and approaching coding with the mindset of ping-pong pairing helps strengthen our development practices. If you’re unfamiliar, ping-pong pairing has one person write the spec, while the other implements it, allowing for a great learning opportunity for the junior partner. Although it can sometimes default to the more senior partner implementing while the junior reads along, it does help drive good practices for both. Having a frequent coding dialogue ensures both developers remain actively engaged.

00:17:26.720 From my experience as a junior, the first month at Mavenlink where I had never seen the codebase was very challenging. I felt like I contributed very little for a while, which was disheartening. It’s easy to feel out of place when you declare yourself a web developer but hardly touch the computer at first. To combat this, you should follow along intently and closely observe your pair’s coding style. The style you learned may be valid, but it is imperative to adapt to the codebase’s style. I had worked on my own projects with a specific coding style, but now, it was essential for me to align with the established code practices at my new workplace.

00:18:40.000 I learned by observing the senior developers deal with challenging problems: they often implemented code in their style to get the specs to pass and later refactored it to fit the company's coding standard. It was crucial to learn to ask the right questions if something wasn’t clear. As a junior, it is your responsibility to voice doubts; I made it a point during my interviews to share what I didn’t know and wanted to learn. A company with a pairing culture expects you to ask questions; don’t hesitate to interrupt and ask even if it seems like they are in the middle of a thought.

00:19:56.960 When it comes to driving during pairing sessions, operating the keyboard can be intimidating and may feel slower early on, especially when you’re paired with someone who types faster than you. However, it is critical to practice asserting yourself on the keyboard; it contributes significantly to your development. There have been moments where I completely held back, letting the more experienced developer take the lead while I followed along. However, I have made concerted efforts to drive more actively in the last six months, and I can say it has helped tremendously, so I urge you not to feel apprehensive about that.

00:21:24.360 As a senior developer working with a junior, you should explain the reasons behind your solutions if the junior doesn’t seem to grasp them. For instance, we might be performing object checks and comparing objects within the context of code and instead of just writing 'object.account.equals(account)', we prefer to write 'object.contract_id = contract.id'. It may seem minor, but it saves on database lookups and provides equal efficiency in comparison logic. Explaining this logic to the junior developer might not seem necessary, but it greatly helps cultivate understanding.

00:22:56.680 When it comes to ping-pong pairing, it’s important to let juniors drive, and encourage them actively—all the while explaining the why behind solutions. This pairing contract makes sure that you have clarity of boundaries regarding the roles of each person working together. Another worthwhile recommendation is to demonstrate your style versus the company’s style during your pairing, as it’s beneficial for the junior developer to understand different perspectives and coding approaches.

00:24:14.680 The style difference can lead to productive conversations about best practices. You can encourage test-driving code, ensuring that you focus on getting your specs to pass before refactoring. You implement your solution in a way that reinforces these practices. I have discussed using methods such as inject, which might not be familiar to a junior. It’s not uncommon to use methods in a flexible manner, depending on the context, especially considering familiarity and what might be clearer to them.

00:25:54.080 Our exploration of certain coding strategies happened during a project we worked on, ultimately spawning some solo work as well. My own soloing began to balance personal interests with work tasks, which I initiated by throwing ideas around in the office. For instance, since I was familiar with setting up a Minecraft server on AWS, Andrew gave me the green light to play around with our CI server, which I ended up building. Although I cannot recommend this process to junior developers outright, I found the experience fulfilling and insightful.

00:27:33.280 That being said, I urge caution; if you find yourself offered a chance to set up a CI server, think twice. Jenkins, while valuable, was challenging to operate, and moving to Travis came with its own issues. However, I’ve learned that soloing can still be beneficial in specific scenarios; during quiet periods like breaks, I’ve engaged in long personal projects, which have cemented my sense of ownership over my work and help me feel more committed. There’s a downside to pairing since you lose individual ownership over certain projects.

00:29:40.800 During past holidays when everyone was away, those still in the office would sometimes work on solo projects. I took this time to orchestrate a feature I had a personal investment in, and when it was time to return, I couldn’t wait to integrate my work into our codebase. The inclusion of individual contributions is where pairing falls short, but communication remains vital. I could ask about side projects while still collaborating with others, allowing me to see how my projects fit into the larger scope.

00:30:57.120 One last point I would like to emphasize is when hiring a junior developer, look for those who demonstrate not merely a desire for a paycheck. They should show engagement with the role—from my experience in San Francisco, I have noticed many people entering the tech scene without much passion for engineering. Oftentimes, they might be seduced by the profits and benefits but aren’t equipped with the drive necessary to develop. Identifying those who truly seek to learn will lead you to the best junior developers, and as evident from my own journey, passion can stand out even when faced with obstacles.

00:32:33.120 I’d like to think I’ve contributed significantly to Mavenlink since being hired as a junior developer, and I am grateful to the community that supported me throughout this journey. Additionally, I am equally thankful for the resources and mentorship I received, which served as a strong foundation for my growth. If you have experiences to share or questions to ask, I urge you to come talk to me. I’d especially love to speak with any junior developers, as I know it can feel daunting.

LoneStarRuby Conf 2013