Coding Academies Are Not Nonsense (for some people)

TechCrunch posted a clickbait-y article last week titled "Coding Academies Are Nonsense." My husband sent it to me a few days ago and I initially just rolled my eyes at it, but then kept thinking about the various parts I disagreed with and how I might deconstruct it...so fine, a blog post.

tl;dr - If you're considering attending a code school (which I imagine is the intended audience of that TC post), read this ebook by my friend Katie instead: So You Want To Go To Code School

To start off with, here are some of the points in that article that I agree with!

1. Code schools' marketing messages can be misleading ("instant employment, a salary big enough to afford a Tesla").
2. A lot of what code schools do is that they find people who were already capable of learning to code on their own ("I take people that were always meant to be software engineers, and I rectify that mistake." -- one of my instructors at Hackbright)
3. "Unlike human readers, computers cannot infer meaning from ambiguous text. So, to code, one must become very good at deconstructing problems into their most basic steps and spelling them out for the idiot box."
4. "[Coding] is a skill that anyone with intelligence and determination can learn."
5. There are many free resources on the internet, which you should at least try out on your own first.
6. There are people who go to code school who could've done more ahead of time to see if it would be a good investment for them. (see this previous post, How do you know if you would like programming?)
7. There are people who have successfully taught themselves enough coding to land jobs as developers.
8. "The best education comes from years of practice and learning"

And now, for the points in the article that I think are incorrect or incomplete.

Fallacy #1: there are no additional benefits to attending a school for learning to code when you can learn for free
Counterpoints: benefits include social pressure to get yourself to do something you wanted to do already, guidance towards a particular curriculum, and faster learning from having concentrated help

Before I went to Hackbright, I had taken a couple part-time night programming classes and never felt like they really stuck with me such that I could move beyond the classroom exercises. A big part of it was that I have many other interesting, enjoyable interests competing for my attention, and since I didn't need to code for my dayjob, I didn't have to keep progressing there. And my previous career was good enough in many ways, in terms of the people I got to work with and the pay.

Career-wise, I wanted more, but I also needed help to achieve it. So a huge part of why I took a sabbatical and attended the program was that the discipline and focus needed to move forward quickly would be imposed on me. It's not unreasonable to pay other people to impose social pressure on you to keep showing up; that's a large part of why people work with personal trainers and such, right? You could go to the gym and work out on your own, because if left to your own devices, you just don't, but by spending money you could make it happen, why not? Is a person who's only fit because they pay a personal trainer for help, any less fit than someone who does it on their own? That attitude sounds like "only the accomplishments you achieve on your own are worthwhile" to me.

Another big benefit in learning to code in a school environment is access to other people (instructors, TAs, peers) that guide you along a particular curriculum, are familiar with your progress so far and can untangle your muddled questions to guide you to figuring out the answer. The article even mentions this:

"In more than 20 years of personal experience with coding...I’ve noticed that the vast majority of folks hit a wall early in the process."

You could find a technical mentor who might help you with this, but will they be there for 40+ hours a week? Are they experienced with teaching someone from your background? Do you know what the next thing you should learn is (a surprisingly decent, but probably still overwhelming chart for this), or will you flounder around and try dozens of "Intro to ____" tutorials? Or you could try asking the internet, and then possibly get yelled at by strangers for posting a duplicate question, only you didn't know that previous answer existed there, because you didn't know the right words to look for, and then maybe they just give you the answer without caring all that much about how to teach you so you learn in the future. 

In a good code school environment, you can use that help to keep building positive forward momentum until you've had just enough successes to become addicted to that high when you solve the puzzle, as well as the confidence that given enough time/effort/help from others, you are capable of finding an answer to the mystery and bend that stupid computer to do your will.

Fallacy #2: code schools are only about learning to code

Counterpoints: you can also get access to a hiring network, possibly a feeling of legitimacy from going through an "official" program

A large part of the value that a code school offers is its network of partner hiring companies that they introduce their graduates to. Ideally, these companies have tempered their expectations for candidates from this source versus other recruiting avenues.

I've also talked to people who learned a fair amount on their own, but felt like they had to "prove" the legitimacy of their knowledge by going through a program first, in order to open up those networking doors. This reasoning for going to a code school does seem a bit risky to me for the money involved, so I usually counsel against it, but I know of people for whom this strategy worked. You can't separate their eventual success in meeting their goal (landing a developer job) and determine whether their going to a code school was a cause or a mere correlation, but hey, they achieved their goal.

Fallacy #3: the end result of attending code school is becoming a "full-fledged programmer"

Counterpoint: the end result is a demonstration of your aptitude and capacity for learning a lot of technical information in a short period of time

"In 20+ years of professional coding, I’ve never seen someone go from novice to full-fledged programmer in a matter of weeks"

My biggest piece of advice for code school graduates interviewing with companies is that you should be completely open about how aware you are of all the things that you don't know, but the reason they should consider hiring you is that you've shown that you're really, really good at learning. If they want proof of your tenacity, then surviving the intense environment of a code school should qualify as supporting evidence, much like coding on the side for years and years would be.

Fallacy #4: you can only get a job as a developer after getting the "best education" from years of practice and learning

Counterpoints: whatever you spent your time on when you weren't learning to code can probably still be applied in some way, plus companies hire code school graduates on their potential

A hesitation I had before switching careers was that I felt like I was throwing away the career that I'd built before and just starting over entirely, but then I learned that there were plenty of ways that previous skills I'd developed still translated over. My Biology degree? Running experiments to test hypotheses I have about my code. My technical troubleshooting customer service job? Hunting down bugs, and understanding what customers say. And so forth.

So, no matter how junior a developer you are, there are still ways for you to contribute. If there weren't any expected value, then companies wouldn't make offers, that'd be bad for business. One my favorite quotes from the talk I gave on being a better junior developer is from my friend Katie M: 

"No one comes out of their mama's womb knowing how to code." 

Everyone starts somewhere. And getting paid to learn stuff (by spending a lot of time asking questions and looking things up on the internet) is basically the true description of what a modern-day developer does. If you end up arriving at that "best" education some day, great! I hope you've gotten promoted and are well-compensated for it! But "not there yet" is not the same as "this is all nonsense."

Fallacy #5: only people who are sufficiently motivated/passionate/capable of learning on their own can become true programmers
Counterpoint: how you learn to code and your motivations for doing it are largely irrelevant

"Most people don’t find coding enthralling or interesting enough to continue to pursue it as a career."

"But programmers are a natural resource. Only so many people have the will and ability to do it."

 If I could just tack on a "entirely on their own" to those statements, it'd be fine. But just because some people have found success after years of learning at night, working on projects on the weekends, doesn't mean that everyone else who missed out on getting a Computer Science degree or tinkering in high school has to follow the same path. Who cares? Sure, there's something to be said for how the top 1% of programming skill is probably more achievable if you spend all your spare time thinking about it because you love it so much but...there's nothing saying that you have to be in the top 1%.

I love this post on The Moderately Enthusiastic Programmer from Avdi Grimm:

Even more problematic to me is the idea of being passionate about a product. I care about doing good work, certainly. I take great personal and professional pride in it. But am I really expected to be passionate about something I’ve been hired to help build? Do we fire members of construction crews if they don’t show a strong enough emotional attachment to the office complex they are building? Do we even fire architects for that offense?
...
There is a part of me that is genuinely fearful of the effect on my future hire-ability, when I admit the following: no, I will not be passionate about your product. I will be professional about it. I may even be excited about it, if it happens to be something that I think is neat-o cool. I may have a ton of fun building it. But that doesn’t really matter. You’re not hiring a Juliet to your project’s Romeo. In the final analysis, you’re exchanging goods for services.

After all, to quote the article:

"There’s a dearth of skilled coders"

Questionable prediction about the future: 

"Coding skills will continue to be in high demand until technology for software creation without code disrupts the entire party, crowding out programming as a viable profession." 

I'm a little skeptical about that claim, but regardless of its truth, if in the meantime before that happens, you can still get yourself to a better and more fulfilling job than what you might've had before, there doesn't seem to be a ton of opportunity cost here to me.

Conclusion

I really enjoy my job as a developer, and I am forever grateful for having been able to switch careers into it. Before learning about code schools, I didn't even know it was a possibility, outside of spending years and many more dollars going back to school, or giving myself a second full-time job, neither of which I was going to do. As a result, one of the things I really can consider a "passion" now is working to break down those barriers of entry into this field. It's a wonderful, stimulating, and cushy life! (if your tech job isn't, talk to me about joining New Relic) Just because you didn't choose to attend college and major in Computer Science when you were a teenager doesn't mean that it can't happen for you!

I understand that that's pretty hard for a lot of experienced developers to swallow. Some of it is the common tendency for people to believe more strongly that the way they did things was the right way (see: med schools making students pay for the privilege of working many hours on little sleep, all hazing rituals ever, etc.). Some senior programmers may be frustrated by the amount of help the newbies need to get going, and code schools cause there to be more newbies on the job market. I also think some people intuitively sense that having a greater supply will decrease the status and compensation for existing programmers, even if no one admits that out loud.

But ultimately, people are capable of making their own decisions, and I support having many alternative pathways to entry. If you are considering going to a code school, I strongly recommend buying a copy of this ebook by Katie Leonard, So You Want To Go To Code School. She's a friend and co-worker of mine, and I gave her feedback on early drafts, but I don't get any commission from her sales or anything. It's the best compendium of pros/cons/points of consideration that I've come across and it's not put out by a code school, so it's as unbiased but still useful as you'll be able to get.

Notes from webinar on creating inclusive presentations

Technically Speaking ran a webinar today with @judithmwilliams and co-hosted by @feministy on creating more inclusive presentations. Below is a writeup of my ~4.5 pages of handwritten notes from the webinar :)

• Judith's intro to the topic: did a lot of work on Google's unconscious bias training
• Know who your audience is
• out of a desire to connect, we tell stories, but that can then end up increasing the disconnect with the audience
• ex. speaker told a story about her triumph over blindness, but for visually impaired member of the audience, exhausting to hear her life articulate as the worst thing to ever happen to someone
• Imagine ways in which what you say might be received differently by people different from you
• Know yourself--know your biases
• we normalize our own experience, have a hard time imagining a different way
• proactively seek out other ways of knowing
• try to understand the stories that aren't being told
• What the goals of your presentation?
• might be to convey knowledge, but can dig deeper at your goals too--maybe to persuade?
• all stories have positive and negative manifestations in them--so you can reproduce or undermine common biases in stories
• think about who's included or excluded
• think about metaphors used in the story
• Recognize our limitations
• Can't be all things to everyone
• Be transparent about who is excluded and why, can highlight others better equipped for those stories
• Q: how to prepare a talk for an audience in a different country/culture from your own?
• You can ask conference organizers for a list of where people are from
• Make the presentation more accessible to everyone
• give handouts ahead of time
• Get people to be more physical, with low stakes ways to participate (raise hands, then raise hands higher, then have people stand up if they can relate)
• Giving speakers feedback
• "I think you had good intentions, but here's how this resonated for me"
• "Hey, that wasn't cool"
• Q: what to think about when prepping slides?
• Accessibility: consider those who can't see or can see very little
• videos: have captions
• images: describe verbally what's in them
• text should be big enough, high enough contrast
• (these are universal design principles anyway!)
• Use a variety of examples and photos: gender, ethnicities, ages, etc.
• are you reproducing inequities? are there patterns?
• show people of all different abilities
• ok to use aspirational photos of what you want your workplace to look like
• applies in writing too: pronoun usage
• Don't want ideas about inclusion to becomes weapons of exclusion
• Create a checklist for yourself, like the Bechdel test -- @judithmwilliams's version!
• Are you showing people that are different from you?
• Are you showing different people doing different things?
• Are you actively challenging biases and the mainstream narratives?
• Q: sources for images?
• Getty images
• search for "free"/"open source" + image you want, then check attribution
• ask individuals to be models in your own photos--don't have to use glossy stock photography! Don't be afraid to be unpolished
• Geography: try paying attention to how we talk about geography and spaces
• at Grace Hopper Conference last week, supposed to be for all women in tech, but lots of talks/data from North America -- rhetoric that tech only happens in San Francisco, not anywhere else, but then if it's in a developing countries, then given an award for it
• Discourses of safety => discourses of race and exclusion (some discussion around stereotypes people have of neighborhoods/countries that are "safe" or not, and people evaluating safety based on people's skin color in those areas
• Q: how to show people different from yourself but not get into cultural appropriation?
• In photos, if using them as examples of an idea--just an example
• When telling stories: whose story is it?
• ok to tell other people's stories!
• but do your research
• be honest about who you are, why this story, or this culture, for illustrating your point
• is it a convenient stereotype that we use vs. an illustrative story?
• surprising stories, that against the common narrative, are actually more interesting anyway!
• make sure you're not using a trope as an excuse
• Kind of like recruiting--diversify your network ahead of time, so don't have to default to an undiverse pool to draw from
• We could do a lot more for more age-based inclusiveness.
• Example: using an older woman programmer in your story, without having to comment about it
• Ask yourself: am I representing a different point of view?
• Q: how can you tell if you're being funny?
• see if your jokes land
• be careful who the joke is on

(I think they went on for a bit longer after this point but we needed to leave the meeting room I'd booked at work for us)

Continuing education at work (talk)

This talk was presented in Portland at PyDX 2015, in Detroit at self.conference 2016, and in Cincinnati at RubyConf 2016. I previously mentioned these continuing education programs in this blog post.

Quick links to resources:

• Book recommendations list
• Talk recommendations list
• Talk nomination form example (please make a copy)
• Stickers! Designed by the amazing Virginia Poltrack

Abstract:
The list of things we want to learn is infinite. How many of us have marked talks to watch, or books to read, yet have never gone back to them (until our browser crashes and we lose everything that was in an open tab)? Left to my own devices, I often only learn what I directly need in my work, despite the best of intentions. It wasn’t until I started running a couple lightweight continuing education programs at work that I followed through on my goals around continuing to expand my technical knowledge base. This talk will discuss setting up programs to finally get yourself reading those technical books and watching technical talks. We’ll discuss strategies for making these programs low maintenance and long-lived, as well as flexible enough to help both more and less experienced folks. If you’ve been looking for a more structured approach to self-education, this talk is for you!

RubyConf:
self.conference:
PyDX:

Response to my talk, on Storify: PyDX, self.conference, RubyConf

Appendix of painstakingly nitty gritty details I didn't include in the talk:

General items:

• How do you gauge initial interest in these kinds of learning groups? 
• Find ways to work it into conversation. When people ask you what's going on or what you're doing, say, "I'm considering starting a ___, what do you think? Would you be interested in participating?"

Logistics:

• Picking a day and time:
• Early in the week is good, not enough time to be pushed aside from pile of work to get done before the end of the week, have had the weekend to catch up on reading if needed. We have Technical Book Club on Mondays and LunchConf on Tuesdays.
• Time of day: not in morning, to have lunch time to do reading for book club.
• Weekly cadence is nice because you don’t have to question whether it’s an on or off week, but if every other week is needed, that’s ok too.
• Calendaring:
• Give everyone modifying rights to calendar event, to be able to add others (in general, have open editing permissions).
• Set up calendar events for yourself for any logistics items that need reminders, then don’t have to remember, get prompted by calendar notifications.
• Tracking: I started tracking attendance somewhat surreptitiously, just in case I need some data on participation to show management. But I haven't actually been asked for that yet.

More details on Technical Book Club:

• Book recommendations:
• We're keeping a running list of recommendations, trimmed regularly (like if the person who suggested the book isn't around anymore and none of us left have any interest in it)
• Solicit recommendations from larger office/engineering teams (also a way to publicize the group!)
• Voting on books:
• About 2 weeks before current book is slated to end, announce in various channels that next book is being decided upon.
• We review the choices, to remind people what each book is about and why we might want to read it.
• Then do runoff voting, everyone gets 3 votes in the first round (and can double up on one selection if they want), 2 votes in the second.
• Ordering books:
• If the book is written by an indie author and you have ties to the community, doesn't hurt to ask for a group discount! Authors seem delighted when people read their books as a part of a book club.
• Expensing: just because there isn't an official education budget doesn't mean there aren't funds to use, ask! Sometimes not an official budget because they don’t want to set a ceiling on what people think they can ask for, but on balance, books are very good value for the company when compared to sending people to classes and such.
• Reading assignments:
• Wrap up discussions with settling on next reading assignment.
• Don’t want to be stuck on the same book forever and need to feel like making forward progress each week, but not be hugely time consuming. Aim to finish the book within 2-3 months.
• ~30 pages or 1-2 chapters usually about right, depending on space taken up by sample code. It's about what people could get done in 1-2 hours.
• Post the assignment in the chat room and put it in the header--want to make it really easy for people to look up what the assignment is without having to ask someone else.
• Post a reminder the morning of book club on what the reading is.
• Also announce who agreed to facilitate the next meeting, so everyone knows and it's recorded.

More details on LunchConf:

• Have a form (example to make a copy of) for submitting talk nominations, from what people have seen themselves and thought was really good, or from blogs/Twitter.
• Minimum required fields: title, link to video
• Additional info: speaker name, talk abstract, length of talk (rounded to nearest minute, for easiest sorting), link to slides
• Include a link in the form description for how to view previously submitted nominations, so you don't get duplicates
• Calendaring:
• I have a room that's booked for an hour and a half. We always start 20 min after the hour to have time for A/V setup and people to get lunch, then 30-35 min talks, then a bit of time after for people to use the room to stay and whiteboard or discuss if they want to, but can also leave in time for 1pm meetings.
• Room booking and invite event are two separate calendar events, and attendees are only on the shorter event. That way, we don't get kicked out of the room, but it's not a scary looking 1.5 hour block on someone else's calendar, only mine.
• Choosing talks to vote on:
• Facilitator gets to pick 3 options.
• Good to try to pick a spread of topics so there’s a diversity of topics and appeal.
• If there are shorter talks, bundle a couple short ones together. 
• Voting:
• Initially counted votes manually (keep it simple), but then used the HipChat bot Polly. Now we do reaction voting in Slack, which is nice for allowing people to vote for multiple options rather than just one. The talks recommendation spreadsheet also has a copy of the generator I built for the Slack messages, making things easy by allowing you to just copy/paste to set up the voting.
• Announce which talk won in the chat room at least 30 min before people leave to get lunch, so they can decide whether to attend or not.
• Video playback tips:
• I use the youtube-dl command line tool for downloading videos from YouTube, that way won’t have streaming or connection issues
• Oftentimes there will be multiple videos you can play for a talk, try to pick the one that seems highest quality/most official. 
• If possible, check any comments on the video in case video is corrupted in some way. Be suspicious of a video that's shorter in length without an explicit description that it's actually a shorter version of the talk, versus a corrupted video of the same talk. (I'll note that this is the ONE exception to ever reading YouTube comments!)
• If you want to try playing the video at a faster speed, easiest way seems to be get Quicktime 7 and adjust the playback speed using the A/V controls panel (under the "Window" menu).
• I find we can go as fast as 1.25-1.5x, depending on speaker pace and density of topic. If the original talk is 50+ min though, then it's usually better to just play it over 2 weeks instead.
• After the talk is over, try to find the slides and share with the group, helps reinforce the topic. If possible, good to have slides handy even beforehand, in case the slides aren't easily visible on the video.

[Update] Great post from James Cheng about how he implemented LunchConf at his workplace as well! I especially like the tips on how to include remote teammates.