Resources for learning about personal finance

When I was around 20, I started to be really really into reading about personal finance. I was fortunate enough to have come from a very comfortable middle class upbringing, where my mom started training us from an early age to balance a checkbook and use credit cards responsibly and that sort of thing. Probably the most important thing was the sense that money wasn't magic, and learning what to do (or not) with it was a reasonable and achievable task--basic math + skepticism of "too good to be true" situations + figuring out your own psychology (that's the hardest part).

So I was curious to learn more once I had to pay for my own stuff and over the years, I've developed the below set of recommendations (some specifics only applicable in the U.S. though). I wrote this up for an email to a co-worker a couple months back and have wanted to reference its contents since then, which is usually a good sign that I should turn something into a blog post so that I can be lazy :D Links below are affiliate ones, but I would look for them at public libraries first.

My go-to recommendation for people just getting into managing their finances better is On My Own Two Feet: A Modern Girl's Guide to Personal Finance; I suppose I have mostly talked to women about this in the past. I don't remember the "for girls!!" part of it to be too annoying, just that it wasn't too long or overcomplicated. Ramit Sethi's I Will Teach You To Be Rich also has good coverage, so you can just decide which title/book cover you're less put off by, probably.

I think Your Money: The Missing Manual is probably also good, I used to follow his Get Rich Slowly blog (until it was sold and the type of content changed). He had a series of 14 posts that went through his core principles about money (Tenet #1: Money is more about mind than it is about math, & so forth). Probably a good place to start if you're from a family without good role models for personal finances.

If you want to get into investing, I really enjoyed The Bogleheads' Guide to Investing -- I actually read this in its entirety during a cruise to the Caribbean! Their follow up book on retirement planning was all over the place though, I definitely don't recommend that. The tl;dr for the book is put your money into large index mutual funds with a brokerage that charges low fees, like Vanguard. I've been mostly putting my money into various "target retirement" accounts, where they'll adjust the ratio over time, with a bit extra into certain low-fee stock funds because I'm ok with having a bit more risk there.

Overall I put in effort up front to figure out a system for my money (this much towards savings each month, etc.) and then I can just lightly monitor that, rather than have to do stuff more actively. I shove as much as I can into the various accounts and then let it sit there to grow without fussing or worrying over it (more on this in the "misc" section below).

The order of operations that I consider the sensible order for getting a handle on your money is:

1. Figure out where your money is coming/going currently: I have a rough budget set up in Mint, but mostly once a month I sit down to review everything and do a month-over-month comparison to see expenses by category and net income. You don't have to do it like that, you just want a sense of where your paycheck is going and what your debts are.
2. Automate savings/bill payments: I dislike remembering due dates but also paying late fees.
3. Emergency fund of at least 6 months of living expenses if you were to have no income at all. This should be in a savings account where you can withdraw this cash at any time; I have an account where I get slightly better savings interest rate if I use my debit card a certain number of times a month and do direct deposit, etc. I use Mint to track all my accounts, so I don't mind having a bunch of different ones to look at, and so I'll also take advantage of offers that are like "open a savings account with us and we'll give you $300" since basically that's just a different place to park some portion of my savings for a bit. 
4. Max out any company 401k matching: When I first started working, I poured all the for-retirement money I was diverting from my salary into a pre-tax 401k, because that meant I could max out the match while still having a bit more take-home pay. Nowadays I split it roughly evenly between a pre-tax 401k and a Roth 401k. There are differing philosophies on why you might choose one over the other, but there's guesswork involved in all of them so don't worry about the perfect solution all that much, we're probably all at least a little bit wrong.
5. Max out a Roth IRA: there is an annual limit on how much you can put into these per fiscal year ($5500 for us millennials, more if you're older), based on a sliding income limit.
6. Max out 401k contributions: the IRS annual limit is currently $18,000. In the past I've done it as either at max percentage at the beginning of the year until the cap is reached and the money can start (hopefully) growing asap, and I feel poor for awhile and then I feel really rich when my paychecks are full-size again, but it got annoying from a figuring out household budget perspective, so now I figure out a rough percentage that would spread out the contributions over the calendar year a bit more and then round up, to make sure I don't accidentally miss it before the end of the year. 
7. Pay down debts: any credit card, car loans, student loans, etc. This should be higher up on the list if you have a high amount and high interest rates though, as high as #3 imo. I put it lower because the 401k/Roth IRA stuff has limits on it per calendar year, so if your debts are mostly monthly car/student/mortgage types, that might take you awhile to pay off in any case. But credit card debt should be wiped out much more quickly, the benefits from compound interest in retirement/investment do not outweigh interest rates there.
8. General brokerage investing: if you're going to invest directly in stocks, etc. I have a bit of this somewhere, but mostly the rest of any leftover money for me gets dumped into a general savings account that I'll eventually draw from for a house down payment. I've experimented with smaller targeted savings accounts, like a "just for fun whatever no guilt" and "vacation fund" etc. but that didn't work for me, I'd rather judge based on the expense rather than budget in that way. 

Miscellaneous:

• The "don't worry as much about where you're saving to, just save a ton" thing:
• "What describes most of those years when we aren't saving is normal life."
• "You are not going to beat seasoned, well connected professionals on an amateur basis."
• "You'll have to make up your own mind about what the future is likely to hold."
• You're entitled to a free credit report from each of Equifax, TransUnion, or Experian every year (use https://www.annualcreditreport.com/, not freecreditreport.com), which will tell you what their records say for what debts you have, the accounts you have open, and what condition they're in. I have a calendar reminder to myself to pull one of these 3, every 4 months, so I can spread it out through the year and make sure that the only reports they have are of accounts that I know I opened myself. This won't give you your actual FICO score, usually you have to pay for that separately or get it through a bank/credit card that gives it to you as a perk.
• My blog post on stuff I learned from considering buying a house.
• If you like to travel and don't find credit cards a temptation to overspend, I've gotten a lot into rewards credit cards over the past few years, to get more out of what I'd already be spending anyway. The simplest is pure cashback, the Chase Freedom or Amex Blue Cash Preferred are great for that. Then the next level are all-purpose rewards cards, like the Chase Sapphire, which has an annual fee of $95 but it's been worth it for me. My flights to South Africa earlier this year cost me something like $100 out of pocket, and same thing for my flights next year to Rio for the Olympics. milevalue.com is a good blog for this, and he recently published an ebook. 

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.

What I learned from considering buying a house

Long story short, I was visiting a friend and learned about a house across the street from her that was for sale, extremely close to a train stop to get into the city, and when I looked up the price, surprisingly affordable. We didn't end up making an offer, but I've spent the last 2 weeks frantically reading up on house-buying (in the U.S.) and asking all the homeowners I know for advice, so I thought I'd write up that a little bit.

First, if you're just like "wat is house buying process even", my friends recommended this home buying guide written by Redfin and this other house buying guide by Michael Bluejay (as my friend noted on the latter, it looks/sounds a little spammy at first, but the content and calculators seem well-researched and logical). Reading through those demystified many of the initial steps.

Second, it was a bit different for us because we had a specific house we were looking at, but I tried to set up some additional showings through reaching out to the agents listed for houses I found on Zillow. This did not work out very well, as there was a bait-and-switch on some of them where I had to talk to them on the phone first, only to learn that the original listing wasn't even available anymore. When I said I wanted to work with people that were really good at communicating over email and maybe text, this isn't what I'm picturing...

Incentives matter a lot, with such a large purchase. When we do this process again, I'll probably find an agent and schedule showings on Redfin, since their agents are salaried and only earn bonuses on good reviews, not on commissions. They make it pretty easy to request a specific time for a house showing. I also like that they host a review system for other people you'll need in the process, like lenders and home inspectors. Hopefully this would help me avoid people trying to make a sale based on emotions like "how do you feel when you walk in" as the principle guiding system, when we haven't had a chance to rationally evaluate the objective pros and cons.

Redfin's search capabilities aren't as sophisticated as some of the other sites though. I started off mostly using Zillow (though I learned that many realtors loathe Zillow due to their whole "Zestimate" algorithm projecting home values and such, but that didn't matter to me since I just ignored those numbers anyway) but now I'm trying out Trulia, which has some very useful filtering options, like filtering by commute distance on public transit to a particular address. Trulia also has Pinterest-like board for the houses you've saved to look at, which is cool for sharing with other people you might be searching with.

Finally, I learned that the most useful way to evaluate a potential house is in terms of what would be most difficult yet important to change, and prioritize lower the items that money and/or time could fix. This is why there's that old adage of "location, location, location" for real estate--because that is the one thing you can't change. From there, some other important things you'd want to consider are large trees on the property that are too close to the foundation, as well as the general condition of the foundation itself (check this by going into the basement and seeing if it feels damp, do you see mold/rotting, are things askew). You want to be situated on higher ground, to avoid flooding, and if you like bright rooms, you want your main exposure to be facing south. Stuff like that, versus renovated kitchens or bathrooms. As long as the infrastructure for whatever you want to do is there (plumbing, gas lines, etc.) you can probably make it happen later.

Another point regarding updated kitchens is that the owners have upped the value of the home based on their renovations, but they may have made decisions about layout/fixtures/finishes/etc. that weren't what you would have made yourself, so if that's something you care about, you have more flexibility in buying a house with a crappy kitchen and spending the different in price renovating it after you're the owner.

Of course, many people are looking for places that are move-in ready and don't need much, if any, additional work. That's a perfectly legitimate trait to value, as long as you recognize that tradeoff in cost.

Anyway, looking at houses and dreaming of the possibilities is pretty fun! I now have a bulleted and sub-bulleted list of my priorities that I wrote out, which will be a nicely organized way to score future house candidates :)

Continuing education at work

Update: I gave a talk about this topic and also wrote up more implementation tips.

I've been working as a software engineer for almost two years now but it's really only in the last six months-ish that I felt like I've gotten better at getting myself to learn things while at work that are beyond "what is the thing that I need to accomplish this immediate task in front of me." It turns out that the keys to success, at least for me, are:

1. Get people to do something with me as a group.
2. Don't try to start too many new things at once.

I'm not the kind of techy person that does a ton of techy side projects and experimentation and such outside of work. I have too many hobbies for that! I really like learning new things and I want to be better at my job, but it's best to try to get that done while at work, because I also like having pretty clear work and not-work parts to my life. Fortunately for me, I work with lots of people who are very similar in those regards, and with a little bit of corralling effort, I can take advantage of that to set up social pressure for getting myself to do things I already wanted to do.

For example, I'd heard from several mentors that doing technical book clubs was a good way to learn, so I pulled together some people at work who'd all been interested in reading Practical Object-Oriented Design in Ruby and booked a conference room for us to meet in for an hour, once a week, during the work day. At the first meeting, we discussed a bit about why we wanted to do a book club, what were some pitfalls we might fall into (participation dropping off, going so slowly that people lose interest, etc.) and set some ground rules with the focus of getting ourselves through the book in a timely fashion without being stressed about it. We're on our 5th book now, so that's been pretty successful!

One of our ground rules was that if at least two people were free to meet, the meeting would happen, even if other people had something that came up. The others could just catch up and join in again at the next meeting. We would also assign two facilitators who would commit to doing the entirety of the reading and try to bring code examples to the next meeting. This has dropped off a bit recently, but we got lots of great discussion and it really helped to be able to discuss how we might apply a technique or principle discussed in a book chapter to our actual work projects.

I think of myself as more of an instigator than an organizer; I try to set things up so it's not dependent on me to manage everything, like making calendar events modifiable by other people, writing down any setup instructions so someone can run the meeting even if I'm not there, etc. Mostly I invest energy into prodding things forward so we don't lose momentum. The meeting time and location doesn't really change, so we don't have to spend lots of time figuring out everyone's schedules, and we have a HipChat room for helping to coordinate as well as sharing related resources, like links to blog posts and conference talk videos, which are later added to the book club's wiki page. That page also hosts our ongoing list of potential books to choose for the next round, which we'll vote on to decide as a group. Sometimes it's more Ruby-focused stuff, so the non-Ruby people sit out until the next round, but that seems to work ok if we alternate it with more general architecture or design books.

At RailsConf this year, I got the idea from someone to start a another group at work, during our lunch hour, for watching all those conference talk videos that I bookmark but then never actually watch on my own. I set up a form for people to nominate conference talks (here's a copy of that form), and then the day before our weekly gathering, I pick 3 talks from that spreadsheet for people to vote on. I use youtube-dl to download the video in order to avoid any problems with streaming and Quicktime 7's A/V controls to sometimes increase the playback speed to fit in longer videos. This has worked well for people because all they have to do is show up with their lunch, and they're able to hang around a bit afterwards and discuss the content if they don't have meetings they have to get to.*

So those formats have worked really well for me! I did at one point try to set up a weekly "hey let's hack on things" session, but that was too structureless to get myself to get stuff done and I'd wind up just continuing on work projects. Basically,

Structure + Social Pressure = Success!

In general, I think it's important to not try to incorporate too many new avenues of learning all at once, so that you have some time to focus on making just one new thing into a habit before taking on the next thing. I usually have a mental (or written) shortlist of things I want to learn, so I think at the time of starting the POODR book club, the list was something like, "object-oriented programming, Ruby, and testing," all 3 of which were covered in doing that book club. Somewhere else I had a much longer list of all the things that people kept telling me I should learn, so I'd have to somewhere to at least just put that info, but if it didn't fit my top 3 priorities, I let myself disregard it for now so I wouldn't feel overwhelmed.

I think it's also helpful to try to be a bit organized about how you're going to learn these things, after you've decided on that shortlist of what you want to learn. For example, at one point, one of my three items was to get more comfortable with Angular, and I had two links to recommended tutorials saved for me to be able immediately get started on them when the free time came up, rather than having to spend a bunch of time searching around for where to get started and then feeling unsatisfied because I didn't actually do anything.

If you're somewhere that isn't as supportive of continuing education while on the job, or you're busy enough that it's really hard to carve out extra dedicated time to learn something new, there are a couple strategies that might help with that. One is learning how to make a case to your boss that your taking some time for reading a book or doing a tutorial will ultimately increase your effectiveness and how much you and your team can get done. Another is figuring out a way to shoehorn learning new techniques into projects that you're working on and having the patience to give yourself a bit extra leeway for when you're going to be a bit slower because you're forcing yourself to doing something in a new way that will ultimately be better than the get-it-done way you've tried so far.

Even at the most incremental level, every time you have to look something up to get a task done, you can probably take 5 minutes to read a bit more about that topic and take some notes for yourself so that next time you run into something similar, you know a little bit more than the last time you looked into that topic. Ever since Hackbright, I've kept a daily log of what I've been doing and links to particularly good blog posts or Stack Overflow items, with my one-sentence summary of what I want to remember for that content. I also keep a process doc where I stuff in git commands or keyboard shortcuts I want to remember (though again, I know I can't learn that many new things at once, so usually I have just one post-it note stuck to my monitor of the one new keyboard shortcut** I'm trying to learn).

So the overall strategy is:

1. Figure out the handful of things you want to learn next
2. Figure out the barriers to you achieving those goals
3. Experiment with different ways to help yourself overcome those barriers

Different things work for different people! My friend Katie writes awesome blog posts sharing tidbits she came across at work and then dove into more to come up with great examples for sharing that knowledge. Other people propose talks and learn about a topic if that talk is accepted at a conference.

Don't get down on yourself about all the other things you feel like you should or could be doing--of course you can always do more. However, I'm of the school of thought that guilt is mostly not a very useful emotion and it's better to keep putting one foot in front of the other, with the occasional lift of your head to look ahead and make sure you're progressing in the direction you want.

*We're pretty lucky at New Relic in that one of our VPs of engineering actually reached out to me with a bit of concern over us watching these talks over our lunch hour rather than feeling like we had the support to be doing this kind of continuing education alongside our work projects! We discussed it as a group and decided that watching these talks felt more like entertainment to us than work, and the time would allow for more people to be able to attend, with greater flexibility on topics not immediately relevant for work projects. But we've also had times when people played screencasts in the afternoon too, so timing can vary.

**If you're wanting to learn Gmail keyboard shortcuts in particular, these stickers are excellent for that! there used to be keyboard stickers that would help with those, but looks like they don't sell them anymore :(

Asian parents teach far more than just "rote memorization"

A few weeks ago, I read this piece about Eddie Huang and his complicated relationship with the TV show inspired by his memoir, Fresh Off the Boat, and wanted to pick at something tossed into the article that’s a big pet peeve of mine:

Today the means that many Asian-Americans apply to achieve academic success (a narrow emphasis on rote memorization and test preparation) could not be more out of step with the attitudes and practices of the socially liberal elite that Asians aspire to join.

There are a couple reasons this irritates me:

1. “Rote memorization” is always referenced with a hint of derision, implying certain “better” ways of learning, but in fact, rote memorization is a necessary and useful tool in the learning process.
2. Rote memorization is frequently implied as the sole reason Asian-American kids are so successful in the American school system, and why Asian kids do well on the international tests around math/science/etc.

I really try not to be someone that comes off as looking for things to be slighted by; I think a lot of microaggressions, while definitely real things, might be better ascribed to thoughtlessness and callousness rather than maliciousness. But, the stereotype that Asian kids are good at school because they’re mindless drones memorizing the answers really gets under my skin. I find it distasteful at best, and racist at worst, like it’s a way for non-Asians to pat themselves on the back and reassure themselves that their kids actually are still smarter, because they “let” their kids be more creative, while those Asian parents are stifling it all out of their kids.

Re: #1, sometimes drilling the same concepts over and over is in fact the most efficient tactic for learning something. I have fond memories of my mom making me practice the times table while driving around from one activity to another. Her intent was that those calculations could become automatic so I could use them quickly and get more math practice done in a shorter amount of time, even if I didn’t fully wrap my mind around why you want to multiply things in the first place. It was good enough for a time to just understand that you would have to. Her standard was for everything up to the 9s to be automatic and ideally I would get most of the 11s and 12s, but that could be a stretch goal for an American third grader. None of this messing around with boxes and such like they do in Common Core.

This is how effective methods of teaching programming can work too, like the first few chapters of Learn Python the Hard Way. When there’s so much new stuff being thrown at you, sometimes the best way is just to be willing to accept and take things for granted. If you stop to examine every single little piece, you won’t get somewhere fast enough to keep going with the learning. Learning to compartmentalize what you don’t understand yet is a very useful skill.

So, that’s #1. For #2, yes, a lot of Asian parents have their kids parrot answers. In our town, my mom once heard of a family where the dad went and somehow bought years and years worth of the problems posed during the math league challenges. He then had his daughter do all of them, essentially memorizing the answers in advance, since those questions don’t change that much.

But I think more importantly than that in Asian parenting culture is the emphasis on schoolwork as important and your job as the kid. Your contribution to the family unit is to do well in school, since for better or worse, the ENTIRE FAMILY is oriented towards clearing barriers to the kids doing better at school. My sister and I barely had to do any chores, we always had a quiet place to do homework, and if we needed something for school like getting to the library, my parents would drop everything to make it happen.

They taught us that grades were earned through study and hard work, not a result of natural ability or at the whims of the teacher. If it was a math or science subject, my parents would never have accepted “the teacher gave me this grade” versus “I could’ve studied harder” as the reason behind mistakes on a piece of homework or a test.

Even teachers not being good teachers wasn’t a sufficient reason! We were expected to find a way. My parents would try to help us as much as they could but in my mom’s case, she would sometimes look at a problem and say it had been too many years since she’d learned that math, but then send me off to figure it out on my own with a reminder that even if she’s forgotten the principles because she doesn’t use it anymore in her day-to-day, the training for our brains in successfully learning it at least once was invaluable. So the “but when will I ever need algebra” complaint would never fly. And with my dad, we learned how to teach ourselves pretty quickly, almost in self-defense, because a quick question to him could easily turn into a 3 hour digression about number theory that left you more muddled than before.

Finally, there is of course the classic Asian parent response when you brought home a 99% on a test to immediately ask, “What did you get wrong?” My mom’s position was that American schools, though they had other strengths, clearly had lower standards than Chinese schools when it came to math and science so if she did well in the Chinese system, she fiercely believed there was no reason we couldn’t get top grades here, if only we worked hard enough.

But this emphasis on always looking back at past results to see how you could improve—that’s a hugely useful lesson for a kid to learn! Even before it’s helpful to being applied to the work environment, just think about the typical course structure: you start with some introductory topics, have a few exams or a midterm in between, and then you have a final that covers everything. They’re set up to build on previous concepts, so going back and reviewing your earlier mistakes both cements the foundation for the more advanced topics and also grants you a leg up on all the sections of the final that are about the early topics.

I certainly recognize the enormous amounts of privilege that my parents gave us. Even though they both grew up materially poor in China and Taiwan, my maternal grandparents were a chemical engineering professor and doctor, and both my parents were able to come to the U.S. and later attended graduate school here. So they carried plenty of that implicit knowledge around education and clawing your way up through the middle class and could gift that to us. (Though I will also note that there are Asian kids who do well at Stuyvesant whose parents don’t have college degrees and have menial day jobs) I also am more than happy to grant that school grades are very flawed measurements in many ways, and an overemphasis on school can have tragic consequences.

But for the love of god, please don’t dismiss everything Asian parents teach their kids about school as “mere rote memorization.” You may not agree with their methods, but you should try to analyze and learn from their approach if you’re feeling insecure, not seek to diminish those parents’ and kids’ accomplishments.


Further reading:

• The Fresh Off the Boat memoir has some hilarious parts related to food, even if I’m not into the hiphop part of his narrative
• Battle Hymn of the Tiger Mother, for all the controversy people stoked up around it, is another insightful look into Asian-American parenting culture. If people seem like they haven’t talked to many first generation Asian-Americans about their childhoods but want to learn more, I tell them to just read this book instead.
• I Love Yous Are For White People is a raw, painful memoir that I still think about from time to time

Notes from Sandi Metz fireside chat with Women Who Code

The absolute highlight of my trip to RailsConf this year was an event put on by Women Who Code featuring Sandi Metz! Sandi is a widely respected teacher and consultant in the Ruby community. She really focuses on clear explanations and her talks are set up so that people at all experience levels can get something out of them. And as it turns out, she also has great insights to share about making technical decisions, getting up the courage to start giving talks, and so much more wisdom generally.

Below are my notes for the session, but WWC actually managed to record the whole thing too! It's an hour and 20 minutes long, but I might even watch it again myself, even though I was there (the person that's kind of loud and asking lots of questions? That was me!)

Anyway, I tried to clean up my notes and roughly rearrange them by general category.

Her own background:

• music student but then into votech school for data processing—this is fun story, you should listen to it
• no thought at the time (late 70s) that CS was only for men
• There are different types of programmers: she likes understanding the shape of the whole from the details, into abstraction
• great for her to partner with Katrina Owen because Katrina is the opposite, derives from the bottom up

Definition for simple code:

• “the inebriation test” — look at code you didn’t write, after you’ve had a few drinks
• if you’re really smart, will write simple code
• code that seems inevitable later actually required a lot of time to write
• sequence diagram on whiteboard first, figure out objects & message
• insist that things be simple—refuse to write complex code
• leaned Object-Oriented (OO) by writing OO code
• hadn’t read literature on it
• there are easier ways to learn this: Steve Freeman & Price - Java & testing book, GOOS
• Rebecca Wirfs-Borck — single responsibility design
• Eric Evans Domain-driven design (PDF short version)

TDD

• already done design work
• TDD easy when you know a lot of design
• sequence diagrams helpful because then rest is implementation detail, don’t have to worry about writing code that you get attached to
• TDD: sucked at beginning, now vastly improved code, always find bugs
• don’t remember how small objects work, but ok, have tests
• tests of the right kind, don’t test everything
• believed in people who said TDD was a good idea (they’re lying or otherwise not good enough yet) — bosses would’ve said “good enough” without it

Monoliths vs SOA:

• lots of revolving door software — don’t have to deal with consequences
• but in real world, app will live a long time, app gets bigger
• the next shiny thing, not Rails, is coming
• want to be able to change part of your app to newest thing, without having to port over your entire app
• big monolithic apps hard to change -> go out of business
• breaking up large app without OO into services — will fail
• need to isolate bits of app into objects
• “find the seams” — then extract into another app
• network latency is a problem, but want to get there
• edges with clear APIs

Preview of her RailsConf 2015 talk:

• if is always with an else
• even if about that thing, it’s a specialization of that’s also a thing
• missing code
• objects to embody holes in your code
• yin & yang if you have a thing, then model the absence of something. just as real as a thing, need it for good OO design.
• “nothing is something” null object pattern
• like inventing zero, just as real as everything else (this analogy was actually a question from me, that then got a shoutout in Sandi's newsletter! I'm still a little giddy about that!)
• biologically wired to be good at people names
• yield the block (true) vs ignore the block (false)
• if/else without conditionals
• true - true yield the block
• false - true ignore the block

Writing books:

• nobody would read POODR while it was being written, hated writing
• finding a voice — writing is hard enough without owning your voice, so do it, bend it there
• couldn’t do academic tone
• well just going to be goofy, didn’t want to write book anyway
• new book: 99 bottles, first 2 days of course — join this mailing list!

Coming up with talk ideas:

• your perfect audience: the you that didn’t know what you know now. past you would be very sympathetic, very grateful
• don’t keep from doing things because of people who know more
• create content for people who know less
• people better than you—motivating to learn, strive
• there’s someone out there who needs you!
• judge yourself against the right people
• looking at people’s talks — she’ll help people in Hangouts
• there’s science about performing under stress like public speaking (“Choke” book)
• everyone is terrified the first time, no way to know if you’ll get over it until you try it
• don’t judge based on talks at work
• don’t decide in advance you can’t do it
• “good enough as an explainer & slide-maker” to get across idea
• “praise is great but unhelpful” — how to improve?

Making technical decisions:

• I know I’ll be wrong, don’t have enough data
• choose the errors that are the easiest to recover from
• learn to make many small things
• then fix it later, err on side of small until you know it’s too small
• bet that you’re wrong
• DRY — deciding that 2 things are the same, adding in an abstraction
• much easier to deal with duplication
• easy to fix problem of finding duplicates
• going from 2 (duplicate) -> 3, might decide you have enough information now
• but if you know there’ll be 4, duplication for the 3rd item, wait for #4
• hard to recover from bad abstraction

Other topics:

• career advice: commitment to learning over writing 80 hours of code a week — that feels like it’s truth as dominant culture, but only inside the cave
• functional programming — immutability, no side effects
• can write function OO code
• book: functional programming for OO programmer
• create subdirectory namespace under ActiveRecord for models
• things in model can be plain old Ruby object, to manage business logic
• not have concerns in Activerecord, AR just for managing database
• drive edges of framework apart
• make AR not the center of the universe
• naming things:
• use local experts on names, or else have a time box on deciding on names. make a best name you can change later if needed
• what story will these names tell to the next person
• care about the names
• “not the last book you’ll read”
• you have a right to be here
• have to help each other believe
• if you’re somewhere invalidating, get outside support or leave
• can’t fix everything

Complex conditional formatting in Google Spreadsheets

I quite like organizing things in spreadsheets generally and of course had a fair amount of familiarity with Google Docs & Spreadsheets after working there for 5 years. Among other things, I more or less project planned my wedding and all its associated craft projects using Google Spreadsheets.

One of my favorite features is conditional formatting, which helps you do automatic color-coding based on the content of the spreadsheet! Very useful when you want to see at a glance which items on a list might still be incomplete or is in danger of being late.

I recently discovered an addition to the conditional formatting options that lets you set the rules across multiple cells at a time, based on the content of multiple cells. This was a big deal for me because I’d previously thought you could only change the colors of a cell based on that cell’s own contents. However, sometimes you want the rule to be based on the contents of multiple cells taken in conjunction together. Before, I’d have to put in a new column somewhere and then base the rule off that extraneous column. And I wouldn’t be able to change the color across an entire row with the result, just the color for that one cell.

The new feature is a “Custom formula is” option, along with the ability to apply conditional formatting rules across a whole range. With this, you can write formulas that combine multiple cells’ values together and change all of their colors based no the result.

In my example, we were doing a prioritization exercise at work where there two different kinds of effort estimates, with L = Low, M = Medium, H = High. We wanted to be able to see at a glance the highest priority ones, which would be HH, vs. the lowest priority ones as LL or any other combo, like MH which is more important than HL.

It took some finagling to figure out exactly how to write the custom formulas to return the correct True or False values that the conditional formatting would then use to judge whether to apply the color styling. You have to use the dollar sign to pin the ranges in the right spots. Here’s what I ended up with:

• Apply to range: A:B (the two columns I want to be colored based on the formula’s results)
• Red for =concat($A:$A, $B:$B)="HH"
• Orange for =or(concat($A:$A, $B:$B)="MH",concat($A:$A, $B:$B)="HM")
• Yellow =or(concat($A:$A, $B:$B)="LH",concat($A:$A, $B:$B)="HL",concat($A:$A, $B:$B)="MM")

Which brings us this result:

Pretty awesome, right?? Project managers everywhere should rejoice! You can make a copy of my example spreadsheet from here.

Ask vs. Guess Culture Communications

This talk was presented in Detroit at self.conference 2015, in Berlin at eurucamp 2015, in Chicago at Write/Speak/Code 2016, in Braga at RubyConf Portugal 2016, and in London at The Lead Developer UK 2017.

Abstract:

Have you ever been told you’re “too direct,” or feel like you don’t understand what others want? Or on the other side, do you think others are often too confrontational? These are Ask vs Guess Culture differences. Ask folks believe it’s ok to ask anything, because it’s ok to say no, while Guess folks prioritize not imposing on others. It’s a culture clash that isn’t often recognized, yet causes quite a bit of tension and frustration. This talk will cover the nuances of these different communication styles, as well as strategies for bridging the gap. Gaining an understanding of these differences and learning specific tactics for a professional context will make you a drastically more effective communicator.

eurucamp slides, Storify:

The Lead Developer UK: slides, Storify
RubyConf Portugal: slides, Storify
Write/Speak/Code: slides, Storify
self.conference: slides, Storify

This was the original ~9min lightning talk I gave at a company engineering offsite:

How do you know if you would like programming?

I’d had some scrawled out notes for this post sitting around for ages but fortunately, Alan went ahead and wrote an excellent post on the topic! Some of my favorite points from his post:

• Your current technical ability with a computer is not a good measure of your technical aptitude.
• "You don’t actually need to know much math to be a programmer"
• "It’s not that you’re not smart enough, it’s just that programming can be really difficult"
• "When I say ‘you enjoy programming,’ what I don’t mean is that you are having an enjoyable experience the whole time."

I would recharacterize the “mental endurance”/grit section of it a bit. I think it’s a particular kind of grit, or tolerance for frustration, when it comes to programming. This is my favorite comic for describing what it feels like to be a programmer:

I also tell people from my old career that coding brings me really high highs and really low lows, but the highs are high enough *for me* to put up with the lows. And I don’t mind this particular kind of low as much, where some small detail missed somewhere is the actual cause of the problem, or it turns out that what we thought we were telling the computer to do isn’t what we were actually telling the computer to do.

Computers are really dumb! We all want to throw them out of the window, often! But when you get that feeling, are you the kind of stubborn to dig in your heels and get into a battle of wills with this inanimate object? That’s what helps you keep going until you get another hit from a successful solution. I think this tolerance for frustration is a kind of muscle that you can build over time, but I also think it’s not a coincidence that many programmers are really annoying to argue with or get to change their minds.

Alan put in some questions to ask yourself for the aptitude part:

• Do you enjoy puzzles? 
• Do you speak another language? 
• Are you able to describe and explain news events to people? 
• Have you helped plan a large event before? 
• Do you play an instrument?

Here are some more questions that might help:

• Do you enjoy hobbies where you have to put things together from smaller pieces? Example include: cooking, knitting, crocheting, sewing, woodworking, mechanic…
• Do you like organizing things, either in real life, or in things like spreadsheets?
• Do you have and enjoy using a label-maker?
• Do you like puzzles, either the physical kind or like those math logic puzzles where you have to fill out the charts based on your deductions from given statements?
• Are you a DIY type?
• Do you like figuring out how things work and building them?
• Do you like tinkering with things just to make them a bit better?
• Are you at least a bit lazy and will spend extra time overall so you can use your brain to figure out an easier solution to something (relevant xkcd comics: one, two)?
• Are you able to hold arbitrary rules in your head and compartmentalize to set aside certain things that you don’t quite understand right now but will think about later? 

But ultimately, Alan is also completely right that the barrier to testing out whether or not you’ll like programming is fortunately pretty low—there are plenty of places to get started! I’m hoping questions like those above and in this post will help encourage people from all backgrounds and ages to consider learning programming and we can leave the old “good at math and science” heuristic behind.

How to decide on companies after graduating from a coding bootcamp

Someone asked* me about how I judged whether companies were a good fit for me after graduating from a bootcamp, so here are some scattered thoughts on that.

First, I hated feeling like I was a supplicant begging for these companies to take a chance on me. That’s a fair viewpoint from a particular perspective, but generally not a very useful one for my confidence levels, and one that I would strongly argue away if it were happening to a friend of mine instead.** I believe strongly that everyone has their particular strengths they can bring to a position, regardless of their experience***, so with focusing on that, I wasn’t going to run after a company that didn’t like me, after I’d done the best I could in whatever their interview process was.

The company should understand that they’re taking me based on my potential and learning aptitude. I wanted to be somewhere that I’d have to room to learn on the job and not feel pressure to Already Know All The Things. I was very clear in all my interviews that I didn’t care so much about the content I was learning as the support and mentoring I might receive, and patience and good faith, in return for me working hard to get up to speed.****

One way I evaluated that was whether the company had taken on other bootcamp grads before, ideally from Hackbright as well. I figured that way, the company would have more reasonable expectations for what having me as an employee would be like. I admire people that are trailblazers, but I think being one is probably often a bit lonely and frustrating, so it’s easier to ride on someone else’s coattails a little, if you can.

Then I had the general things I personally look for in a working environment. There are some great blog posts out there on good questions to ask during interviews, like this one from Julia Evans, or this article on getting the inside scoop at a company before accepting an offer. For me, it’s very important for it to be a place where people learn from missteps made in the past, to be able to make different mistakes in the future, while being honest that it’s impossible for things to be 100% sunshine all the time.

I’d ask questions like, “what’s a mistake people at the company have made and how was it addressed?” I’d want to know whether the pep talks given by management seemed grounded in reality and humility. And at the same time as all that, that there wouldn’t be much time or energy wasted in just general grumbling or pure complaining and whining.

Finally, I know people will consider taking “less than ideal” jobs to get a foot in the door at desirable companies. I think this can go different ways depending on people’s circumstances and temperament. Finances and desire for stability are also a huge part of it, and there are plenty of successful post-bootcamp careers that aren’t with the title “software engineer.”

But in general I think if you accept something with the idea that you actually already know you want to move to a different position at that company, do your due diligence in having informational interviews on what their policy on internal transfers is. Be prepared for a more uphill battle than what they try to sell you on during interviews. Not that people are going to lie to you, it’ll just be the rosiest view of the possibilities due to their incentives for getting you to fill the role they currently have open, so go in with your appropriately sized sprinkling of salt.

* over a year ago…when I was giving practice talks for How To Be a Better Junior Developer…so this draft has, uh, aged a bit. But thanks again to whoever suggested that idea! Delay not due to you or the quality of the idea in the slightest, but pretty much only because it’s hard for me to summon up the energy for writing since I inevitable end up rambling for a while.
** One of my favorite tactics for stopping negativity spirals in my head is to remind myself, if a friend of mine were in that situation, would I say (or even just think!) such mean things to her as I was doing to myself? Never! And I would be absolutely outraged if anyone dared to treat her the way my internal monologue sometimes treats me! And then I tell myself, even if I don’t feel deserving of kindness for myself right then, I am a sufficiently not-awful human being to have friends around who would come to my defense as well, so I owe it to them not to be so mean to me. A bit meta and circular, but effective for me.
*** If you need help figuring this out, it helps to talk to someone else to get an outside perspective. Even with fixing up my resume or writing my quarterly accomplishments, it’s always felt easier to talk about how to enhance other people’s descriptions of their work than my own necessarily, so you can do a trade. Also my How To Be a Better Junior Developer talk is pretty much all about how you can contribute even when you’re new, so check that out for more of my thoughts on the matter.
**** Some of the hiring managers at New Relic would get slightly fondly exasperated with us from Hackbright all just being like “we just want to learn!!!” and wanted more specifics, to help figure out good fits for us, especially if multiple teams like a certain candidate. So it’s useful to figure out more detailed answers, to expand from “I want to learn everything” to “I have more of a preference of learning this backend part of your stack because I think it’s cool that _____ but I’m also interested in the frontend too because _____” which if you think about it, pretty much sums up to “everything” anyway.

Advice for your first talk

I’m going through and clearing out very old blog post drafts. This is from a randomly long email I wrote to the Hackbright listserv of advice for someone giving their first talk, after I’d given my first talk How to be a Better Junior Developer at RailsConf last year. The main point I’d add to all this is that you don’t have to succeed at All The Public Speaking Things all at once, on your first few talks. It’s easy to get swallowed by all the information on public speaking out there, so if you’re getting too overwhelmed by it all, I think it’s more effective to ask yourself:

1. What do you want your audience to get out of your talk?
2. What do you want to get out of having given the talk?

For example, for my How to be a Better Junior Developer talk, the answers to these questions were essentially “get them thinking about all the non-traditional strengths they bring to a team” and “give a talk at a tech conference.” Then later I could know that I succeeded, since I’ve had lots of conversations with people about the former, and I didn’t literally die, so I succeeded at the latter as well!

One of the reasons I wasn’t super thrilled immediately after that talk was that I had some secret (even to myself!) goals that I was caring too much about, like wanting to be validated by getting the audience to laugh, or having a flawless delivery that matched up exactly with the script I’d written out. It would’ve been better to save those for future talks, not to mention explicitly stating them, which would let me see when they’d need to be adjusted to be more productive (no one else cares about how well it matches against my script).

For example, it’s a future goal of mine to be able to do the thing where you don’t need to refer to speaker notes at all and can just wander around out in front of the protection of the podium. But for my Slighty Less Painful Time Zones talk, my goal was to give a talk with code in it, with clear explanations and generalizable lessons for the audience. So it was ok that I still wanted to stay behind the safety of the podium and reference my speaker notes there.

Finally, related to all the above, getting better at public speaking is a continual quest. One of the reasons I started reading about improving at public speaking was that I figured this was one of those skills where no one would ever be like, "oh, so-and-so is too good at public speaking." There’s always room for improvement! To that end, these are the resources I use to learn more about how to improve:

• Observing what I like/dislike in other people’s talks (sometimes I get distracted by the meta-ness and have to remind myself to be paying attention to the content too, not just the delivery style)
• Reflecting after each talk to note to give future-me a list of what to do better next time (like after RailsConf 2014 and RailsConf 2015)
• The Eloquent Woman (blog)
• Technically Speaking (newsletter)
• Presentation Zen (blog, doesn't update that frequently)
• Femgineer’s Confident Communicator course looked excellent in the preview webinar I attended, hopefully I’ll get to take it some time!

Talk content:

• Once I knew I was going to give a talk, I kept a running doc of all the random ideas that came to mind that I thought I might want to fit in, other articles that came up that seemed like they'd be relevant, until I had enough of a mass of material that I could cut down to fit 30 minutes, vs. like with writing papers when I always felt like I was stretching to reach the word count.
• Write up at least your talk outline first, outside of making slides. Much more work to fiddle with slides later if the structure of your talk isn't pinned down yet.
• Sometimes I write out an exact script and practice it until I can do it off referencing bullet points or ideally no speaker notes at all, but that takes a lot of time. Practicing it out loud helps me realize which turns of phrase are fine in writing but sound awkward out loud, or that I have trouble remembering. I'm trying to become more flexible about this kind of thing though, so I think it depends on how much you would benefit from the extra structure.
• People love personal stories, make yourself relatable to evoke empathy and help people feel like they're getting more out of your talk. Basically you’re like, “I’ve been where you are, I understand you, here's how I got out and how you can do it too" and it gets received as, “I’m like this person, so what this person says is relevant to me...that was such a great talk!!"
• Asking rhetorical questions are an easy way to get "audience participation" without feeling like it's too much of a strain. I did a ton of, “Show of hands, how many people have felt this way before??" and raised up my own hand to get people to see that I expected a response.

Talk length:

• If you think about it, few people ever say, "man, I wish that speech was a lot longer." So it's better to hit 20 minutes and leave them wanting more, than going way over time allotted for a 30 minute talk to 40 minutes instead.
• Related to that, I’m always reminding myself to try to sloooooow dooooown. My default speaking speed is on the faster end of things, and when I get nervous on stage it can get jerkier and squeaky--not a very effective delivery mode for me. So adding in uncertainty for whether I can finish in the allotted time doesn’t help, and it’s better to think I can slow down as much as I want and not go over.
• Or, think about the talk as a series of mini-talks that you're stitching together. Might be less intimidating to pull together three 10-minute talks than one 30-minute talk?

Technical details:

• I used Keynote for the first time and loved it, if you have a Mac and can get access to it, it's definitely worth trying out because they basically set it up so that it's hard to make ugly slides. Could be worth seeing if you can expense it. (see this post I wrote on slide building tips)
• Look at a handful (but not too many) other speaker decks to get a general sense of designs/formats/structures that you like. Then just blatantly copy one of them and sub out for your own content--unless this is a talk about design, people won't really care that much about the slides themselves for you to spend enormous amounts of time on them. My slides, other random sets I liked. 

Dealing with nerves:

• Power pose
• Put a positive frame on the stress you feel
• Doing a handful of jumping jacks right beforehand (this way I can tell myself my elevated heart rate is due to exercise instead of nervousness)
• Whatever else you need for you, even (especially) if that means being completely anti-social and not talking to anyone beforehand
• Don't apologize for being new or not having a lot of time to prepare, but you can expose your vulnerability to get people on your side to root for you, if that works for you. So like, instead of "sorry this talk was kind of last minute...", you can say "I'm so excited to be here! I'm a little nervous though, so I'd really appreciate it if you all _____" (a friend of mine filled this in with "encouraged me by clapping whenever I get to a section title slide or take too long a pause" which worked really well for him, but he's also just kind of very charming and adorable)
• "How to Talk to Developers" by Ben Orenstein is good, ~30 min long. There's a really good set of practical tips around body language and such near the end, so stick with it.

Other:

• Practice practice practice. Don’t be shy, corral people you know to be guinea pigs and get feedback from them before the real thing. Practice at local meet ups, go to local code schools to be a guest speaker, etc.
• Practicing in front of the bathroom mirror is something I find helpful, because I know immediately if I'm making eye contact with myself.
• Including practicing taking breaks to drink water!
• Include practicing with a clicker, there are lots of remotes you can set up to use as a clicker. It lets you be a bit looser than if you’re tied to hitting an arrow button.
• You will probably forget to say something you planned on saying during your talk. Who cares! It's more important to convey your overall message and connect with the audience than to remember every detail of your planned talk.
• Relax and enjoy the experience; the audience will too! It is the most amazing adrenaline rush you're done and it's gone really well, so use those nerves to pump energy and enthusiasm into your talk.