I love reading other people’s blogs, but I’m terrible at keeping track of all the great stuff that’s out there. I’ll read something, think to myself, “hey that was super cool!” and promptly forget about it as I go on my merry way. NO MORE! I’m starting my own series of blog posts about other great blog posts. Here’s part 1!

  • Garann Means breaks down the different types of criticism you can get and gives some good insights on when to take that criticism to heart and do some growing versus when to say “haters gonna hate” and move on.

  • Phillip Guo reflects on his Hacker School residency. I was so impressed at how thoughtful this post was. Despite spending only four days at Hacker School, he has a deep understanding of what Hacker School is about and why it’s so awesome. He is also really good at giving nice tl;drs if you’re strapped for time. A must-read if you’re wondering what it’s like to be at Hacker School – he’s dead on with almost everything he says. One day, though, I will write a long post discussing this statement: “The closest approximation to this experience [Hacker School] is being in a well-funded Ph.D. program with an open-minded and supportive advisor.” In 2013 I went from a (well-funded, awesomely-advised) Ph.D. program, to Hacker School, then back to the Ph.D., and there were some major differences.

  • Speaking of my awesome advisor, Jeff Leek totally owns his I-tried-and-got-rejected moments. The best quote in there was “to be successful, you have to be willing to fail over and over.” It was so reassuring and encouraging and motivating to know that even people who are really great at what they do experience rejection a lot, and I thought it was really cool that Jeff was willing to share this with the world.

  • Allison Kaptur takes readers on an adventure in systematic debugging. I liked this glimpse into Allison’s thought process: everybody works through things a little differently, and I like experiencing the way other people approach problems. I also ruminated on this line (from the introspection section at the end) for a long time:

    “Whether I should have done this [systematic debugging] depends on your perspective: at Hacker School, I’m almost 100% learning motivated and about 0% get-it-done motivated, so my time to solve the bug is virtually unbounded.”

    This is SO NOT how it usually works when you’re doing research or getting a PhD - you must produce results and get stuff done or they won’t give you a PhD. But I also wonder if taking the time to do things simply for the sake of learning actually makes you better at getting things done in the long run? Allison’s systematic debugging rabbit hole will probably cut lots of time off her process next time she has to solve a string/regex/efficiency problem.

  • Garann Means makes the list again - she wants YOU to blog about code. Honest, inspiring, and funny (reaction gifs are encouraged). One of many highlights:

    “If you start thinking for even one second that [your blog post] isn’t valuable, try to picture you yourself finding such a thing when you started your day this morning and all the agony and yak-shaving it would have saved you. The internet is full of horrible crap! If your horrible crap is at least well-intentioned, it’s probably a step up from the other horrible crap.”

  • Jake VanderPlas writes about the Big Data Brain Drain from academia. I love that he articulates very compelling reasons that computational people could (and do) leave academia, and then suggests some ways that academia could incentivize those computational people to stay. Worth a read for any academics in a computational field.

  • Emma questions whether math-puzzle-solving ability == coding ability. She talks about her experiences getting hired and working as a software engineer and wonders whether the problem-solving interview questions really indicate whether someone will be able to do the job they’re being hired for. It’s a great read.

  • Paul Hinze compares the developer cultures of pairing and code-review. He gives great definitions of what pairing and code review are and goes into a lot of detail on when/why each approach works and doesn’t work. I’m not a software developer, and I still found this post fascinating: I think the ideas translate to collaborative research (Should we actually do our work WITH our co-authors? Or should we each bring our results to the next meeting?). It was also nice to get a detailed picture of what it’s like to be a software developer in one or both of these cultures. Finally, there’s lots of material throughout the post about the qualities of good code and good programmers.

Keep blogging, and keep sharing the cool stuff you’ve read!