June 17, 2015

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 :(

June 10, 2015

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

June 8, 2015

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

June 1, 2015

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.