RailsConf 2018 Recap

I went to RailsConf last week and it was an amazing experience. DHH's keynote reminded me why I love Rails. Eileen's keynote made me super pumped for Rails 6. And all the talks were a delightful reminder of why I love programming and why I love the Ruby community. Here are some deeper thoughts and notes, divided up by talk:

Note: I'll post links to talks that I reference as soon as they are up.

DHH's keynote

This talk really hit home for me since I was very recently battling with Play for 4 months. One of the things that I do really love about Rails is that I can focus on solving the problem I actually want to solve, not problems that have been solved before (like... authentication). And, while I do agree that junior developers and people just starting out should not have to know SQL, I do think that knowledge of SQL is still useful if you want to be a good Rails developer. Relying solely on ActiveRecord is a mistake.

Crash Course in RSpec: stubs and doubles and mocks -- oh my!

This workshop managed to be both good and not quite what I wanted. I had hoped by the title that there would be a big emphasis on stubbing, but it was more of a footnote. It was a good crash course though and if you don't have much prior RSpec experience, check out Nicole's tutorial.

Interviewer Skills

Jennifer Tu of Cohere gave an excellent workshop on interviewer skills that I have about 4 pages of notes from that I will try to sum up here. One of the first things she brought up was that a team should have specific goals in mind when interviewing:

• What values does the team have?
• What characteristics does the candidate have?
• What actions does the candidate take in certain situations?
• What makes someone successful on my team?

For each attribute that the interviewers want the candidate have, they should ask questions that dig into how a candidate behaves. For example, if your team values kind feedback, instead of asking "Do you give kind feedback?" or "Are you nice when responding to pull requests?", ask "Have you ever given feedback to someone whose code was not good? What did you do? Why?". If you value independent learning, ask:

• How do you learn something new?
• Do you have an example of a time when you ran into code you didn't understand?
• Share a time when you had a problem dumped into your lap but you had no idea what to do.

Make sure to wrap a question in context to ensure the candidate fully understands what you are asking. For example, one of the attendees wanted independent thinkers and people who would question decisions. They were currently asking this question:

You get a user request to add a blue button. How do you add a blue button?

However, in the context of an interview, someone who would normally question a decision like that might resonable think that the interviewer just wants to know if they know how to add a button to a page in HTML. What they should ask is:

We get a lot of feature requests and they aren't always valid. What would you do if you got a feature request to add a blue button?

Allow interviewees to show the skill if you can. Theoretical scenarios often just end up only showing red flags. Play acting is the better option. For example, if you want to know if someone gives kind feedback, give them some bad code and have them review it. If you want to know how they handle conflict, play act with the two interviewers coming up with conflicting ideas and ask them how they would resolve it.

It is the job of the interviewer to give the candidate the opportunity to show off. Interrupt (politely) if needed. You will be doing them a favor! Here are some possible polite interruptions:

• I like where you are going with this but....
• I'm sorry to interrupt, but I'm really curious about...
• This is interesting, but I really want to hear more about...

You should also be sure to set an agenda and share rubrics with other interviewers ahead of time.

Pairing: A Guide To Fruitful Collaboration

André Arko gave this talk on the best way to pair and, as someone who has paired incorrectly for a while, it was quite interesting. So the basis of pairing is two devs, one machine.

Discover & share this Ncis GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

I can't not use this gif even though pairing is not this.

Anyway! You should be actively collaborating. The best way to think of pairing is to think of it as one little meeting. If done right, it should push you to be a better dev and away from bad habits. Above all, pairing needs trust. If you are condescending, that breaks the trust of your pair and makes you a lousy pair. One good way to pair is to have the driver write a test, codes until the test passes, writes a new test, then switch driver to the other person, who then repeats the process. Never say "let me do this quickly by myself." That is not pairing! Help the driver solve the problem and stay on the same page, so you both understand. There's a lot more to this talk, but I think you should watch it yourself 😃

The Practical Guide to Building An Apprenticeship

Megan Tiu built out the apprenticeship program at CallRail and so we get to learn from her experience! To start an apprenticeship program, you need:

• plan (what are they going to do?)
• cash (pay them!)
• buy-in (convince the boss!)

You can sell it by noting that apprenticeship programs:

• eliminate onboarding costs (you get to teach a newbie developer your way of doing things)
• eliminate recruiting costs (why pay a recruiter $10K when you can give it to your apprentice)
• easier to hire seniors (who love to mentor)

Here's what you want to know about your plan:

• How long will the program be? (suggestion: 3-4 months)
• How many apprentices do you want to have? (ensure there are enough seniors to mentor them)
• What should they know prior to starting? (do you expect them to have a basic working knowledge of Rails?)
• What should they learn?
• How will they learn it? (through tickets, a big project, pairing, etc)

For hiring your apprentices, you want an application (basic questions to get to the heart of what they are about), a code challenge, and a final interview. If possible, do end-to-end anonymization until they get to the final interview. You also want to ensure you have a rubric prior to starting this process. After you hire them, try giving lessons on foundation concepts, then give them small changes (bugs/internal code). Then rotate them around to different teams, including customer facing product. And don't forget to set early expectations!

Eileen's keynote

Eileen Uchitelle totally pumped me up. She discussed the various ways she is looking to make Rails more scalable by default. One of the things that really stuck with me was when she mentioned how so many companies are doing these things individually... so why not make them part of the overall framework and share the knowledge!

The Code Free Developer Interview

Can you tell I am into interviewing? This was a talk by Pete Holiday, also from CallRail. Here are the problems with coding during interviews:

• don't replicate real work
• disadvantage people without free time (code challenges)
• live coding is very stressful, even for experienced people
• difficult to develop and maintain a good code challenge
• many passive candidates won't do the takehome (I've done this before)

So what's the solution? The primary solution is to just talk to candidates.

• Ask all the candidates a consistent set of questions
• Define a rubric ahead of time
• Write down thoughts right after the interview

That's it! But there's more. Here are three possible techniques for a code-free interview:

1. Dig into their experience. Let them direct you to what they feel is most important. Ask questions like:

• What was your role in the project?
• How does the feature work?
• What's the worst technical debt? Why hasn't the team fixed it? How would you fix it?
• Has it had any bugs/outages in production? What happened? How did the team fix it?

2. Have them do a code review. If you choose this, make sure you are not using production code (they will have no context), are actively reducing complexity, and include realistic bugs without making it a bug hunt. One good option is to have a completely contrived situation with a simple application and a pull request to that simple app. Another is to fork an open source repository and create a contrived PR. The pull request should include no detail in the commit message, unsquashed commits, non-idiomatic code, overly complex, bad variable names, and actual bugs.

3. Try doing a collaborative system design. For this, you want to hypothetically build a tool, platform, or a project. You don't want any code or pseudocode and you should be working with the candidate. The general idea should be easy to understand and either related to the skills you're hiring for or well known. This can be forever-long, so it needs to be timeboxed. Let the candidate lead and build complexity if it's needed. For example:

Let's say we want to build Facebook. Get rid of the boilerplate (we already have users) and then ask "How do we implement status updates?". Once they get there, we can go deeper and ask about privacy controls, then granular privacy controls, and past that potential performance problems.

I loved this talk because I think code-free developer interviews should be the norm and have also been advocating for it at companies that I have been at.

Plays Well With Others: Improv For Nerds

H. Wade Minter gave this workshop and I don't have any notes on it because it was an improv class. But! One of the big things I took from it was our last activity. To remove bias from ideas, we did the following:

• each wrote down an idea on how to improve RailsConf for next year
• exchanged that idea with another person
• each paired up with someone else, compared ideas, and gave each idea a number of points (total points for the two ideas could not be higher than 7)
• exchanged ideas with a different person
• wash, rinse, repeat until we have compared ideas 5 times

At that point, we had seen about 10 different ideas (plus our own) and the best idea could have a total score of 35 with the worst having a score of 0. Our top idea had a score of about 26, with a good number being around 22. We had a couple of bad ideas in the double digits (I'm looking at you, bacon table). This definitely seems like a good practice for any organization with a decent number of people.

And that's it...

I did some more, but I don't have any notes! I also sat and watched my friend Sam Phippen pair for an hour and a half, so if you want to learn yourself some RSpec, watch here!

Building A Community For Beginners

Originally given as a talk at PyCaribbean on February 18, 2017. Modified slightly for the web.

I started programming in Python six years ago and have been doing Ruby development for the past five years. When I would go to user groups as a new developer, it was very intimidating. People seemed to know each other, and I wasn't sure who to ask for help. In the end, I stopped going and just created my own group. But many people get so discouraged that they decide programming isn’t for them.

That’s the reason I believe that building a community for beginners is so important. Let me explain why. We want to ensure that our communities are open to beginners because we need to expand and diversify. The more diverse our community is, the more diverse our teams will be. According to the Harvard Business Review, "working with people who are different from you may challenge your brain to overcome its stale ways of thinking and sharpen its performance."  I also think that everyone should be able to learn to program. Programming shouldn’t be limited only to people who were privileged enough to learn to code in grade school. No matter their age, gender, or background, if someone wants to join our community, we should be open to helping them learn. Having community to help learn should not only be open to people willing to pay thousands of dollars for a code school. I started PyLadies Boston almost four years ago with the express intention of bringing more women into the Python community. I am also involved with Boston Ruby Women, leading weekly study sessions where I answer any questions that people bring me. More on these and a few others as we move on…

How can you do your best to make sure your group is open to beginners? First, let's talk about new groups. As I mentioned, existing groups can still benefit from many of these ideas, so don't totally zone out if you already have a group that you run.

1. Make sure the way you describe your group and events is beginner inclusive

Ex. “no problem too big or small” “good for people of all levels”

2. Be clear about what knowledge and skills are required

Be clear about what level of knowledge is required. People will often underestimate themselves, so keep this is mind when describing what is needed. Ex. “basic Python required, should have mostly completed a tutorial like Learn Python The Hard Way”

3. Find out what your local community needs

This is important. Every community needs different things. With PyLadies, we have a large community of academics and scientists, so there's a huge desire for tutorials and code reviews. With Boston Ruby Women, we have a lot of recent boot camp grads, so we spend a lot of time talking about interviews and finding jobs.

4. Ask for feedback all the time.

Every year, I have an anniversary party and ask everyone who attends for feedback on the past year (what did you like, what did you not like) and for suggestions for the future. This regular evaluation of PyLadies has led us to have new types of events that I would never think of on my own and to get rid of ones that I thought would be successful that weren’t.

5. Try out different types of events for the whole group. Depending on your local community, some may work better for you than others. Here are some event types that I've had success with:

1. Presentation Nights are the standard, but often there's an idea that you have to be an expert to give a presentation. Make it clear when asking for presentations that you are open to presentations about beginner projects.
2. Lightning Talks are a great way to get people to do their first public talk. One of the ways that I have encouraged people is to say that, while it should be related, if you have a hobby that you want to share with everyone, we'd love to hear a lightning talk on it. One of the members of PyLadies ended up doing her first presentation on bird-watching, and it was a huge hit!
3. Tutorials are always successful. They give experienced people a chance to share their knowledge in a meaningful way and beginners a chance to learn a new skill or toolset. However, with tutorials it's key to allow for extra time in the beginning, or before the event, to get set up. Even if you give clear instructions and ask people to set up prior, believe me, you will still likely need extra time.
4. Mob Programming is where the whole group looks at the same problem and tries to solve it together. We started running events that were combination mob programming and code reviews, and they have been a blast. Everyone can participate: even with limited programming knowledge, you can get an idea of what kinds of problems other people are facing.
5. Host separate beginner-focused events. These events will draw out people who are still too intimated to go to the main meetings. We regularly have women show up to our beginner events that almost never go to the main group because they don't feel they are ready, despite my encouragement.
   1. Study groups can help people teach each other. At PyLadies, we try to have study groups every week and have a mentor each time. However, we've also encouraged our members to start study groups in their neighborhoods as well and have had a ton of success with that. I've used these to target people who are just starting to learn to code. If you are trying to provide mentors at study groups, it can be a challenge. One way to sell it to your more experienced members is that it's a way to both share their knowledge and improve their understanding of fundamentals. I have one woman who comes every week who always challenges me and makes me go deeper into the language than I had before.
   2. Mentor sessions are similar to study groups but more focused on career growth. These target people who know how to code and are looking to enter the industry. Job hunting as a junior is often very discouraging, and it helps to have regular meetings with someone who tells you that you can do it. Also, by getting to know a larger amount of junior developers, it makes it easier for you to find great developers who just haven't been given a chance yet. Through these groups, I've gotten two people hired at both Akamai and a previous company. Frequently, it is harder to get to know people in a larger group setting. Having a smaller subset like a mentor session can help your more experienced members get to know the individuals who are just getting started.

So that's some of the basics for starting a beginner-focused group, but what if you are currently running a group? Here are some suggestions that have been successful at bringing more beginners into both Boston Python and Boston RB. I'll start with the simplest:

1. Send an email to everyone who joins with a message that emphasizes that everyone is welcome, no matter their level of programming experience and let them know what they can expect to happen at your events. With Meetup, you can write a message once and automatically send it to every new member.
2. If you can, have someone greet people as they walk in. Ideally, it will be one of the organizers, someone who is there regularly. This individual should do their best to get to know the people who have just joined. It will give all newcomers a friendly face each time they return and someone who is familiar with their level.
3. For presentations nights, ensure that there are regular talks that are suitable for beginners. These talks do not have to be about ‘how to write a for loop,' but more ‘here's a problem, this is how I solved it,' with less emphasis on pure programming. Organizers I spoke to said they got large influxes of new sign-ups for nights when they had multiple speakers from a variety of fields.
4. For project nights, a few suggestions:
   1. Have a couple of beginner tables and, if you can, have a few experienced programmers to staff them and help new people work through issues.
   2. Do introductions at the beginning. Have everyone introduce themselves and mention what they are working on. You can ask experienced people to raise their hands if they are willing to be available for help throughout the night. It can be time-consuming, but it will help build community and create opportunities for people to collaborate.
   3. Reassure people that it's ok if they are not working on a project. You can have people raise their hands at the beginning if they are looking to collaborate on a project.

Ok, last but not least: running workshops and finding the best way to teach people to code.

1. Running workshops is, personally, one of the biggest challenges as an organizer. Here's a rundown of some the problems and some suggestions on how to deal with them.
   1. Space: given that a workshop is at least 6 hours long, you can't run one on weeknights. Therefore, most businesses won't want to host. However, you should try reaching out to local universities and community colleges - even better if you have someone in your group who works at one.
   2. Volunteers are a challenge at any time, but getting people to give away their Saturday (plus maybe their Friday night) is another problem entirely. Expect at least a couple of individuals to bail last minute, so have a backup plan. Make sure to have a few more volunteers than you think you need and be prepared to present if someone who is supposed to present doesn't show.
   3. Content is probably the easiest if you are doing a Django or Rails workshop since there are already full tutorials for both aimed at a weekend time frame. If you want to run a workshop for either of those, check out DjangoGirls, RailsGirls, and RailsBridge. If you want to do a workshop for a different language or framework, consider still looking at those for example of what you should include and adopt it for the framework that you want to cover. If considering a workshop on a language, review the material covered by the Boston Python Workshops. Though the materials are in Python, you could adapt them to fit other languages.
   4. Food - it's important to provide at least lunch when you have people stuck in a room for a full day. You can reach out to local companies who use the language or framework that you are teaching and get someone to provide food. Usually, they'll also want to send a volunteer for the workshop too so they can have someone to represent their company. 
   5. Continued engagement is probably the biggest challenge. When people come to a workshop, make sure they know what the next steps are. When a RailsBridge Boston workshop occurs, they always make sure there is a Boston RB project night the week after so people can keep learning. You could also have lightning talks soon after and encourage people to talk about problems that they want to solve or applications they want to build.
2. There is no "one best way" for teaching people how to code. However, I have had more success with some methods than with others.
   1. Doesn’t work:
      1. Class style setting that builds on itself week after week potentially works if people are paying for it. However, if you are like me and just trying to provide a free service to your community, do not choose this option. I did this when I first started PyLadies because there was a demand for beginner classes. I held classes for just two hours every other weekend. I had a fantastic turnout the first week - 30 people showed up and were super engaged. The second week was still good - 20 people. Then it started dropping drastically. By the fifth week, it was just me and my co-organizer.
      2. Just giving a text tutorial (like Learn Code the Hard Way), with no support. With no support group or place to reach out for help, when people get to a tight spot, they can assume that they just aren't cut out for programming and quit. There's still a stigma that you have to be good at math to be a programmer, and some non-technical people think that only geniuses can program (have been told that I must be super smart because I'm a developer). Often it's just a matter of seeing the right example for a concept to make sense. Just because someone has trouble learning using one resource doesn't mean they couldn't learn using another.
   2. Does work:
      1. Short one-off tutorials on basic programming concepts that don't build on each other. You can't necessarily do a ton of these since most of programming does require knowing other concepts. But you can teach the idea of object-oriented programming without involving a significant amount of code. There are also other languages that you can learn the basics of in a two hour period - SQL being my favorite, but HTML also being a possibility. The goal is to share knowledge, so get creative!
      2. Having beginner focused events where people can bring questions from any tutorial they choose. As I mentioned above, this is an essential part of PyLadies Boston. I always suggest my two favorite tutorials, but if someone learns better another way (say a MOOC or videos), then they can use those and I will still be there to answer questions. I also try to make it clear in all communication that I am always available by email. Unless you have a group that is 5K plus people, this is not as big of a deal as you might think. I make myself available to about 1500 people through the groups I run and countless more through my website, yet I maybe get an email a week max. It will give people a lifeline if they need it, but it will not take up too much of your time.

These are my recommendations on how to build a community for beginners. However you involve yourself, being part of a space where everyone is welcome to learn is a valuable and rewarding experience that can really make a difference to someone just starting out.

Why You Should Go To Conferences

Maybe I'm the wrong person to write this. After all, I only go to one or two conferences a year because I can't quite afford to travel as much as some people do. I check out some local conferences and that's about it. However, I'm inspired to write this because I just got back from RailsCamp East Coast and it was AMAZING. It reminded me of the same reason I love Burlington Ruby Conference and my first PyCon. Conferences (or in the case of RailsCamp, a retreat) set aside a few days to learn some new things and also to spend some time with other developers, building relationships. In a way, it's the best networking you will ever do. Going to loads of meetups and making a passing acquaintance with a lot of people might do you some good. Really getting to know a few people over a few days will do you a lot of good.

OMG RAINBOW (waterfalls near the Ashokan Center in Olivebridge, NY)

I don't mean to dissuade anyone from going to meetups... I have made so many wonderful friends through PyLadies Boston that I would absolutely vouch for and that I've helped get jobs. However, those relationships have formed over the course of years and sometimes you don't have that much time. If you are a junior developer who is trying to get a job, one of the best things you could do is go to a conference and do some heavy-duty bonding. If you can do a talk, that's even better. Anything to show how interested you are in whatever language/field you want to work in. Going to conferences won't guarantee a job, but it will likely increase the number of people who are willing to recommend you to other employers and increase your chances of getting a better job.

If you are like me and a more experienced developer who is not looking for a job, conferences are still beneficial. I love my job, but I'm not going to be there for the rest of my career. When I am looking for a job, now I know even more awesome people who I would love to work with who also know me. This increases my chances of finding a job I actually enjoy since I have spent a significant amount of time with all of these people and have a better sense of who they are and what they value.

TL;DR - Go to conferences (and RailsCamp). They are fun and valuable.