Recommendations for high school students

These are articles/books/videos that I feel are particularly helpful to high school students, for whenever I go to speak on career panels and such.

What to work on

"What You'll Wish You'd Known," Paul Graham
I dislike the dismissal of college admissions officers in this essay, but I support pretty much the rest of it. A few excerpts:

I'll start by telling you something you don't have to know in high school: what you want to do with your life. People are always asking you this, so you think you're supposed to have an answer. But adults ask this mainly as a conversation starter. They want to know what sort of person you are, and this question is just to get you talking. They ask it the way you might poke a hermit crab in a tide pool, to see what it does.
...
Right now most of you feel your job in life is to be a promising college applicant. But that means you're designing your life to satisfy a process so mindless that there's a whole industry devoted to subverting it. No wonder you become cynical.
...
Rebellion is almost as stupid as obedience. In either case you let yourself be defined by what they tell you to do. The best plan, I think, is to step onto an orthogonal vector. Don't just do what they tell you, and don't just refuse to. Instead treat school as a day job. As day jobs go, it's pretty sweet. You're done at 3 o'clock, and you can even work on your own stuff while you're there.

"Building Your Inner Coach" (18min TEDx talk), Brett Ledbetter
Focus on building your processes and systems towards your goals and success, rather than just the results themselves.

"Let's Teach Kids to Code" (17min TED talk), Mitch Resnick
People are growing up as tech users, but not necessarily tech builders. You don't have to think of yourself as a "computer person" to give learning to code a try. But perhaps you should think of it as: do you want to give instructions to computers, or only receive them instead? The former gives you more of the thing that all teenagers want, which is: freedom.


Figuring out what you want to do for a career

Career advice from the creator of Dilbert, Scott Adams

1. Become the best at one specific thing.
2. Become very good (top 25%) at two or more things.
...
The second strategy is fairly easy. Everyone has at least a few areas in which they could be in the top 25% with some effort. In my case, I can draw better than most people, but I’m hardly an artist. And I’m not any funnier than the average standup comedian who never makes it big, but I’m funnier than most people. The magic is that few people can draw well and write jokes. It’s the combination of the two that makes what I do so rare. And when you add in my business background, suddenly I had a topic that few cartoonists could hope to understand without living it.
...
Capitalism rewards things that are both rare and valuable. You make yourself rare by combining two or more “pretty goods” until no one else has your mix. 

So Good They Can't Ignore You, Cal Young

The book that introduced me to the idea that "follow your passion" advice gets it wrong because your aim should be to get really, really good at something. I like to tell people that things you're looking for are pursuits where you enjoy the process of getting better at it.

How do I choose a career path?

I just took jobs I could get using skills I felt reasonably confident I had (for me, at the start, those were writing and being compulsively organized), and then over the course of doing those jobs, gathered and refined information about what I liked doing and what I was good at and what other people thought I was good at and were willing to let me do more of.

The Secret to Being Happy with Your Job: It's not 'follow your passion'

I figured out that biggest mistake I’d been making was asking “What job would I want?” instead of “What do I want out of my job?” In other words, I needed to shift from statements like, “I want to be a writer,” or “I want to be a fashion designer,” or “I want to run my own business,” to “I want a creative atmosphere,” or “I want to work in a team setting.” Because “I want to be a writer” doesn’t actually mean anything tangible.
...
I like data, so I made a massive list of every workplace quality that had given me joy, and conversely, the ones that made me miserable.
...
After that, I started asking everyone about what moment in their job made it worth it. The most memorable response came from an engineer who said his happened when he “solved the problem.” Not when the product was made. Not when it was delivered. Not when it was sold. Don’t get me wrong, many people listed more than one core moment. But it became clear that I needed more of whatever it was that made me stoked.

Informational interviews

Cold-emailing strangers to ask for career advice: some things that you can do that will make people more likely to want to help you

Actually useful questions to ask in informational interviews: "don’t just focus on being impressive (which is the pitfall a lot of people fall into), but think seriously about what you’re really wondering about"

Doing well at your first jobs

5 Mistakes Smart People Make at Work: These are all good points, especially "if you’re used to being 'the smart one' and things have always come easily to you, you might not have built up the skills you need for when things are hard."

What Your Internship Manager Wishes You Knew: all good, especially:

• "Working an internship is different from being in school"
• "college often rewards lengthy explorations of a single topic. In the work world, shorter is nearly always better"
• "Effort is nice, but it’s not what matters" 

A roundup of other relevant Ask a Manager posts for new grads.

15 things you don’t know about work when you’re early in your career: again all good points, especially:

• "I’m the only person who’s fully immersed in my own day-to-day work, and I have to speak up when I want my boss to fix something."
• "leaders are far more interested in how you plan to fix the issue vs. who was responsible for causing it."
• (misconception that) "If a process or tool doesn’t work the way an employee thinks it should, it must be broken and in need of fixing. In a lot of situations where this came up, the employee didn’t have (and didn’t seek out) any background on why we did things the way we did, and just assumed management must be idiots. In reality, there were nearly always valid (and sometimes legal / regulatory) reasons why things worked the way they did."
• (misconception that) "If I see something I perceive to be a problem and report it, my work is done and someone else will fix it."

Other

The UpSide of Down, Megan McArdle
Megan McArdle have been my favorite bloggers to read for several years now, I just like her writing and argument style a lot, and it's informed how I think about things, even if I don't always agree with her. Anyway, this is her book about failure and why it is necessary yet difficult to accept as a part of improving over 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

How to Be a Better Junior Developer

This post was originally published in the New Relic blog on 4/23/14. It is the blog post version of my talk for RailsConf 2014 in Chicago, the slides for which are embedded at the end of this post.

Over the last couple of years, New Relic has hired multiple graduates of various coding bootcamps and “non-traditional” backgrounds, including me! After I earned my Bachelor’s degree, I was actually all set to attend medical school, when I got a job at Google in technical support. Some four years later, I took a sabbatical to attend Hackbright Academy, a 10-week (now 12-week) program teaching women how to code. Before the end of the very first week, I knew I had finally found a career direction I actually wanted to actively pursue.

One of my biggest worries, though, was that I would be throwing away my past experience and the skills I had developed in a different domain, to start over entirely in a new field — one where I’d be up against developers who had decades more experience. Fortunately, as I settled into the role, with the help of the many great mentors I got to work with, I came to the following realizations:

• Being a developer is really about constantly learning.
• There is a lot to engineering that actually isn’t directly coding.

It became clear that there are many ways to leverage the skills I’d developed in other domains, even as a junior developer with so much to learn. Having gone through that period of uncertainty myself, I wanted to spread the following two messages:

• Junior devs: There are ways you can contribute to your team while you’re still learning the ropes.
• Mentors: Tailoring your guidance to junior developer needs will help them feel more confident and productive.

So much to learn

When it comes to the challenge of having so much to learn as a junior developer, the most important thing is not to try to do it all on your own. Here are three approaches you can take:

1. Get people to want to help you
Through building relationships on your own team and across other teams, you expand the network of people you can ask for help when you get stuck. To get the most out of that network, it’s crucial to show that you value other people’s time and get as far as you can on your own. For one, you’ll learn a lot faster if you try it yourself first (Google and StackOverflow are your friends). This also makes your experienced co-workers feel more helpful and confident you’ll put their advice to good use the next time you run into a similar problem.

2. Make it easy for people to help you
It can be really hard to articulate what it is you’re confused about, when you may not even have the vocabulary to describe the topic. Here’s a template that I like to use when asking for help:

“I am trying to ___, so that I can ___.
I’m running into ___.
I’ve looked at ___ and tried ___.”

For example, here’s how I filled this out recently: “I am trying to understand why this banner shows up on this account, so that I can tell the client whether they need to listen to that warning. I’m running into a problem with finding this record. I’ve looked at the model and tried reproducing the issue locally.”

3. Narrow the scope of what you have to learn
Much like tackling a gnarly technical problem, you should also try to limit your scope so it’s not so overwhelming. There are an infinite number of topics you can pursue, but mentors can help prioritize them. (My personal goal: to actually build a Rails app of my own.)


Helping your team

As a junior dev, it’s natural to be asking yourself: how can I contribute to my team when I still need so much help? Something to remember is that in a world where there aren’t enough developers* for all the developer jobs out there, it’s not necessarily a choice between slow (junior) and fast (senior)…it’s a choice between having something built, and not having it at all. Here are some other tactics to keep in mind that will help you give back, above and beyond the code you write:

1. Ask good questions
I like to think of questions as a junior developer’s superpower. Asking good questions, like “are we working on the right thing?”, helps reveal any misunderstandings and assumptions. These would result in many wasted hours if they aren’t uncovered until later in the development cycle, so ask questions early on.

2. Give good feedback
Giving useful feedback to the right person, in the right venue, at the right time, is hard for a lot of people. But all industries have some kind of feedback mechanism, so this is likely something that even junior developers will get a good amount of practice with. You can also help anticipate possible confusion that may come from Sales or Support teams regarding any new releases or product updates.

3. Make your team look good to other teams
Just by being extra responsive, thorough, and empathetic to the other teams that you work with can go a long way. One particularly good opportunity to make your team look good to others is any demos of new features built by your team. You have a chance to demonstrate that your team has been thoughtful about the impact to other teams, like serviceability. I almost always write a script and do a practice run-through beforehand, so that I can ensure a more efficient and less error-prone demo.


How mentors can help junior developers

The above tips are aimed specifically at junior devs, but there are also a lot of things mentors can do to help junior developers feel valued and capable of making concrete contributions. I’m a big fan of having a lot of conversations upfront about things like how a junior dev’s learning style can be matched up with a senior dev’s teaching style. These discussions help make sure everyone’s time is used more efficiently. For example, you might discuss how often a junior dev likes to receive feedback and instructions, and how and when the senior dev prefers to be interrupted if any questions come up.

Also, if as a mentor you want to intentionally let a junior developer struggle a bit in order to learn something, let that person know that this is what you’re doing. This helps dispel feelings of imposter syndrome, where people lose confidence because they have the mistaken belief that this should feel easier, even though it is actually expected to feel difficult.


Conclusion

A junior dev doesn’t show up to their first engineering job as a blank slate. There are many opportunities to hack a junior developer’s existing skillset to help them ramp up faster and feel they’re providing value from day one. I’ll be giving a more in-depth talk today at RailsConf on this same topic, and we’ll update this post to with the recording and slide deck when it eventually goes up.

*We’re hiring!



Response to my talk at RailsConf, on Storify.

Additional recommended resources:

• Team Geek: A Software Developer's Guide to Working Well with Others 
(http://amzn.to/1gyRzAH)
• The Up Side of Down: Why Failing Well Is the Key to Success (http://amzn.to/1kJC0vK)
• “How to Survive Your First Year as a Programmer” (http://bit.ly/1mSoyYI)
• “5 Undervalued Skills in Tech & Why You Should Master Them Anyway” 
(http://bit.ly/1hu796E)
• “Self-promotion for Game Developers” (http://bit.ly/1kdVsmH)
• “Becoming an Influencer” (http://bit.ly/1htNrlt)

On being scared and excited at the same time

I'm not a particularly ambitious person by nature, really. I think a big part of happiness is being content and grateful for what you have, particularly the little things, hence my "Things That Were Good Today" daily gratitude blog. I'm not particularly revved up by calls to change the world; thinking about that just makes me feel a bit tired. A great weekend is often one where I didn't have to change out of my pajamas or leave the apartment at all.

This was pretty frustrating for my mom. When I was growing up, she would frequently ask me, "why don't you want to be the best at whatever you're doing?" and I think it just flabbergasted her that I mostly really didn't care. As a result, sometimes it's hard for me to be an environment where it seems like everyone is always pushing to reach for the next thing just to get to the next level; it makes me wonder if there's something wrong with me when I'm content with what I've got.

What saves me from total complacency is 1, I get bored when I'm not learning anything new and 2, I do want to do things well and to always be improving. It took me awhile to convince my husband that when I asked him his opinion on something I'd cooked, it wasn't a trap, I really did want feedback on how I could make it better next time. These tend to be incremental improvements though, not tackling something big and new and foreign.

For those, this post written by someone who took on skateboarding from Sydney to Wollongong showed up on Hacker News a few weeks ago and though I have never been interested in skateboarding, it actually struck quite a chord with me:

If it excites you and scares the crap out of you at the same time, it probably means you should do it.

If you want to get somewhere in life, no one is going to do the pushing for you. You have to push yourself. 

For me, these two points are totally, totally true. After a childhood of mostly being pushed by my parents, it's taken me awhile to figure out how to push myself towards goals I set for myself. I still need a nudge now and then, but when I think back on the two most significant career moves I've made, I definitely was both terrified and thrilled at the same time. When I moved from the support team to a product specialist role, I was scared of the responsibility it would bring and the impact if I made mistakes, but at the same time, it seemed like it could be a ton of fun to actually have some influence over product decisions. When I decided to apply for Hackbright, it involved not just leaving my job for 2.5 months but also living away from my husband, yet I couldn't stop thinking about the opportunity.

If you had an identity as a smart kid while growing up, there's evidently this whole praise paradox where such kids are more risk-averse and less confident than kids that are praised for working hard instead of being smart. I think this is where the fear comes from, since it's a fear that you won't be good at whatever the new thing is and you'll have risked losing your reputation as a smart person for nothing. This is different than being afraid of doing something really drastic like quitting your job without any kind of backup plan, since this fear shows up even for things that have defined time limits, like Hackbright.

You can tell the difference because it's paired with that nervous excitement, when you find yourself turning it over and over it your head. You don't have to ever toss reason and planning entirely out the window or anything like that, just: pay attention to your intuition. If you feel both scared and excited, you should listen to it.