Developer, Rabble-Rouser
Ruby/Scala Developer, PyLadies Boston Founder, Rabble-rouser
I was recently a guest on the Virtual Coffee podcast! I talked about being a woman in tech, building community, and some random hot takes. I hope you enjoy it.
The official page for the podcast episode is here. The full episode is posted below (but definitely a nicer UI on the official page)!
Last week, my Virtual Coffee small group had a great conversation about imposter syndrome. I had wanted to talk about it because I had seen a request for an imposter syndrome channel in Slack and I didn’t think it would be a healthy choice. So I had some hot takes, which I am now bringing to my blog. First up, let’s define imposter syndrome. Merriam-Webster defines it as:
a false and sometimes crippling belief that one's successes are the product of luck or fraud rather than skill
Historically, this has been a phenomenon seen in high achieving women, which, as HBR noted, is likely due to the negative feedback that women regularly receive. So why does it seem like everyone in tech (particularly developers) have imposter syndrome now? Well, strap in, because I’ve got some hot takes coming your way!
1. People commonly use the term when referring to junior/early-career developers. This is pretty wild to me! If you are early in your career, you, by definition, have not really had any success as a developer! You are just getting started. I think Kim Crayton described this well in a talk she gave on mentoring at PyCaribbean in 2017 (quote is slightly paraphrased):
Learners do not have imposter syndrome. Imposter syndrome is people who have senior level skills and still don’t think they can do a job. Imposter syndrome is not learning. Learning is hard. Learning takes time. You don’t look at a baby who’s just been born and can’t flip over and tell them they’re suffering from imposter syndrome. No you’re not, you just don’t know how to flip over yet! That sounds absurd right?
With that in mind, maybe stop telling junior developers they have imposter syndrome. They are learning! They should not be expected to know everything.
2. Our job descriptions are absurd. I’m pretty happy with my current company (hey come work with us at Splice) because we don’t have 20 different technologies in our job description. HOWEVER: most job descriptions ask for multiple years of experience in both a backend language and frontend framework, Docker, AWS/Azure/Google Cloud, Kubernetes, GraphQL, etc. And you will see that on job descriptions that are not for senior developers. This is especially fraught for early-career devs, who regularly see non-senior posts that are still asking for all of those and 5+ years of experience which makes the job search seem hopeless. Let’s be more realistic with what we need versus what it’s more acceptable to learn on the job.
3. Interviews are an absolute nightmare. If you want to feel terrible about yourself, interview as a developer. At almost any level, you will be told by at least one company that you “aren’t senior enough” or “aren’t technical enough.” The way most companies do interviews also makes it feel way more like it is a personal failing on your part rather than just you and that job not being a great fit (which is actually the case). For example, I have had a broad swath of experience which has enabled me to jump into almost any codebase and be able to figure out (roughly) what’s going on and be able to make improvements. But I do not have experience building applications at scale. If we are being honest, very few people do. If you are at a large company that’s at that scale, you are likely part of a larger team and not making big architectural decisions. Or you might be at a smaller company and maybe have to scale from 100 to 1000, but not any further. Or, like me, you could have spent a decent portion of your career at B2B companies that do not have a ton of users. So why are we making people feel like they suck for just not being the right fit at your company? Maybe we should treat each other better.
4. To that point: talking about imposter syndrome makes it an individual problem. The problem is not with the individual! The problem is how we, as a community of developers, are treating each other. Instead of helping each other grow and lifting each other up, we are constantly putting others down to make sure it’s clear that we are the better developer. There are a ton of jobs! There is room for so many great developers. We do not have to compete in this way.
5. Is talking with others about imposter syndrome actually helping anyone? I think in some ways, it’s nice to feel like you aren’t alone! But when I see people with way more experience than me say that they are also struggling with imposter syndrome, it makes me feel hopeless. Like there is never going to be a point in my career where I can feel confident in my abilities. I can’t imagine what early-career devs are feeling when they see more accomplished developers also struggling. I think talking about it has made it way more of a thing than it should be. Everyone is sad sometimes, but not everyone suffers from depression. Everyone has times that they doubt their abilities, but not everyone has imposter syndrome. But we are at a point where, if you doubt your abilities, you have imposter syndrome. I think this is a bit absurd! It’s turning a normal human experience into a problem that you must solve.
Always happy to talk more about this and am also interested in any other hot takes!
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.
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.
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.
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:
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:
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:
You should also be sure to set an agenda and share rubrics with other interviewers ahead of time.
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 😃
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:
You can sell it by noting that apprenticeship programs:
Here's what you want to know about your plan:
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 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!
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:
So what's the solution? The primary solution is to just talk to candidates.
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:
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.
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:
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.
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!
Yeah, just another hot take on that sexist Google memo. I could only read bits of it because it was just such garbage that I didn't want to waste my time on the whole thing. I also read a few other takes, but it overall seems like standard garbage and it doesn't really surprise me that a senior engineer at Google thinks this way. One of the bits that really stuck out to me was this:
We always ask why we don't see women in top leadership positions, but we never ask why we see so many men in these jobs. These positions often require long, stressful hours that may not be worth it if you want a balanced and fulfilling life.
This just sorta pissed me off because it's ignoring that most women don't opt for these jobs because sexism forces them to do almost all the household labor. Maybe it's also because, as a man, you can have what society deems as a "balanced" life while working long hours because your wife is taking care of the kids and a man isn't considered a bad dad if he's not super involved in the kid's life. This is total crap and bad for women and men that people think this way.
The real downside is that tech is the perfect industry to help even this out since it's pretty easy to work from home in most jobs. In one of my first dev jobs, one of the senior engineers that I worked with worked from home twice a week after his kid was born, alternating days with his wife, so she could go back to work too. I thought that was pretty cool and not a freedom most industries have! Maybe this is a faulty assumption that I'm making since I'm not a parent, but I'm assuming if you have kids you want to spend time with them?
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:
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:
Ok, last but not least: running workshops and finding the best way to teach people to code.
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.
When I moved up to Boston, I felt very lonely. I had my partner, sure, but that's never quite enough. I tried going to existing meetups but I found that they were too large and I still felt isolated. I had been part of a PyLadies group in Atlanta, so I decided to start one in Boston. From the very first meeting, I was energized by the women who came. They were all so excited about the group and the possibilities that it pushed me to spend more time organizing, where I might have otherwise said I was too busy. Every event we had, no matter how small or large, gave me energy and life. It was so gratifying to be able to give people who had never spoken in public before a platform to share their knowledge.
A few months after the founding of PyLadies Boston, I heard about a Ruby women's study group that had formed. Since I was by then working in Rails, I joined hoping to get to know more people in the Ruby community. That group moved from a mailing list to Meetup a few months after I joined and became Boston Ruby Women. That group has also been a source of good in my life. Every month, I'm able to help junior developers not lose confidence during tough job searches. Every month, I talk to brilliant women who routinely give wonderful advice on how to deal with all the bullshit that life throws. The group is always up for a table flipping conversation and I love it so much for that.
I am excited to be moving to Pittsburgh and to start a new chapter in my life. But I'm brokenhearted to leave these two communities. I have faith that I'll be able to meet rad and awesome women in my new home, but I know it will take time. Thank you to everyone who has helped me grow over the past four years. Y'all mean so much to me.