Three thoughts from Ruby Under a Microscope Author, Pat Shaughnessy

I'm reading two great Ruby books right now (reviews will be posted soon): Ruby Under a Microscope
 and  Practical Object-Oriented Design in Ruby. I like them both, for very different reasons.  Today, I'd like to share a little bit about the first.

Pat Shaughnessy (@pat_shaughnessy) has written a great book about how Ruby really works. After getting just a couple of chapters in, I really wanted to pick his brain, and he was kind enough to answer my questions.  Now, I'm sharing his answers with you.

What was the most important thing you learned about Ruby while working on your book?

As I studied Ruby over the past 2 years while working on the book, I’ve been surprised and intrigued by how much of Ruby’s design - and implementation - is based on older computer languages, particularly Smalltalk and Lisp. It’s amazing to me how important the basic computer science research done in the 1960s and 1970s by John McCarthy and his contemporaries really is. It’s almost as if we are all “standing on the shoulders of giants." (Not sure who I'm quoting here…) Learning about these older languages has allowed me to look at Ruby with a new light.

This really hit home for me. I've spent a little (not enough) time looking at Smalltalk and Lisp, and that kind of excursion always makes me think differently about programming (and computing in general).

What do you hope others will take away from reading it?

The main thing I hope readers take away from the book is an understanding and appreciation of the computer science concepts behind how Ruby works. For example: hash tables, garbage collection, closures, stack-based virtual machines and compilers, heap vs. stack memory, LALR parsers… etc. Understanding how Ruby works internally allows me to be more confident while writing Ruby code.

Also, I used a lot of diagrams in Ruby Under a Microscope for two reasons:

• A picture is worth 1000 words - by using diagrams I was able to explain things better than I could have with just text.
• But also, and possibly more importantly, I’d like readers to build up a visual model of what Ruby is doing that will pop back into their head the next time they write Ruby code.

Again, this makes me feel better about my side trips into those computer science topics that I enjoy - until they start making my head hurt.

Now that you've successfully published a (really nice looking BTW) Ruby book, what's next for you?

Thanks! Yea, No Starch did a great job with the cover and interior layout. So glad I worked with them.

For right now, I’m just going to be focusing on doing normal Ruby development work. I also hope to learn more about functional languages such as Clojure and Haskell, and I’m also curious to learn more about other new languages such as Go and Rust.

I also want to continue sharing my knowledge in public. I’ll keep blogging, and might try my hand at screencasts and other forms of media. I just finished producing a guest episode for Avdi that will appear in his “Ruby Tapas” series which I’m excited about. Whatever media I end up using, my focus will remain the same: explaining complex topics in a simple way, and touching on the computer science that serves as a foundation to everything we all do today as developers. 

Post-its and Interviews Part 2

Here's the continuation of Janet and her team getting ready to interview candidates to hire a new team member. (See Part 1 here)

As the team files back in after their break, several people stop in front of the board, looking it over and thinking. Janet calls everyone to the table.

"Ok. We've built a good list here. We've got a couple of tasks to take care of, and maybe a little homework for everyone. Let's start out by talking about our job posting. What should it say? Why don't we break into pairs and see what we can come up with?"

After several minutes the pairs are combined into two teams of four and asked to write a new posting based on both pairs efforts. Several minutes later and the two teams are combined and work on merging their job postings into a final draft.

"Hey, this is a great start, but I think we might want to tailor the message a bit for our different channels," says Cindy, another team member.

"Good idea," responds Janet. "Before we go down that path though, which recruiting channels should we use? Any ideas?"

Several people respond as the lead writes ideas on the white board: the local UX users group, the jobs board at a conference two team members are going to next week, the HR recruiter, and a number of other ideas are all written down. Janet speaks up again.

"I like this list. How should the messages be different for each of them?"

The team dives into the discussion again, coming up with a short list of do's, don'ts, and thoughts about each of the possible recruiting channels. Team members are each assigned a recruiting channel to write a job posting for, and asked to email their efforts to the team tomorrow for approval.

Larry, the senior designer, speaks up, "Ok, if that's out of the way, do we want to build the interviewing team? I really liked the job Susan's been doing leading our reading group. Could she be the primary screening interviewer?"

"I think that would be great! Susan, are you up to it?" Asks Janet.

"Well, I was hoping to be on the main team again, but this sounds like a fun task too." Susan replies.

"Don't worry, we'll look to you for some guidance on what to ask about, and listen for, around books the candidates have read recently." Janet turns to the rest of the team. "Which of our customers should we invite into the interview process?"

Does your team spend enough time before the interview to make sure you'll hire the right people? What do you do to improve your interviewing and hiring process?

Post-its and Interviews Part 1

I was in a meeting room I'd not visited before the other day and I saw a great idea on the wall. At a glance, I saw what another team had been doing.  With a little more thought and discussion with a co-worker, I was able to build a more complete picture of their activity, what it could have been about, and what it could lead to.

An entire wall was covered in sticky-notes, each with a short description on it.  There were inscriptions like: "listens", "thoughtful", "understands user perspective", and "can read code". The notes were divided into groups like: "Leadership", "Communications", "Design", and "Information Architecture".

It didn't take much to realize that I was looking at a team's description of what they wanted in a co-worker. It was only a smaller jump to put together the following scenario.

---

The Web Design Team for Product-X recently had a member jump to another team, and they were preparing to hire her replacement. I imagine Janet, the team lead, gathering everyone in a room and handing out small stacks of sticky notes. Then she would address the team to kick things off.

"You all know what's in our job description. I'd like you to think about that for a moment, then write down some traits you think we need to be looking for. Let's take 5-10 minutes to write them down and put them on the board. Don't be afraid to talk to each other while you're working, we're not keeping any secrets."

I can almost hear the buzz of the team working on this and building on each others ideas. As they wind down, Janet speaks up again.

"Ok, this looks like a good sized list. Let's organize it into groups. If you see duplicates, stack them together and we'll sort them out in a bit."

This is probably a pretty interesting process as clusters of traits are built up, split apart, and moved around. Gradually, the level of activity settles as the team comes to some agreements. Bill, one of the designers might speak up and say something like.
"Hey, I think we're missing some things here in "Leadership" and maybe there in "Design". How about we take five more minutes and flesh these out.  We could work on the duplicates while we're at it."

There's a lot more discussion this time. Some of the supposed duplicates are split off and moved into other groups. Others are recognized as real duplicates and those traits are starred, indicating higher importance. New traits are added to each of the groups. Finally, the energy beings to lag again, and Janet speaks up.

"Ok, this looks like a pretty good start.  I'd like to take a ten minute breather before we come back and get into our next steps."

Everyone files out of the room intent on getting some water, juice, or coffee, and maybe a quick walk outside for some fresh air.

---

I'll post about the follow-up meeting on Thurssday. Do you think a process like this might help with your next hire? Maybe in writing job descriptions for your team (you do have job descriptions, right?)? Have you tried something like this?

Reviewing Annual Reviews

Almost everyone seems to hate end of year performance reviews. Done correctly though, they could be celebrations of your accomplishments. What would it take to make them more exciting, more interesting, or at least less painful?

How about this for an annual review?


Maybe we're not going to see videos with voice-over announcers, screaming fans, or a pulsating soundtrack. Surely we can do better than a drab document that briefly mentions the couple of things that we remember from the last year, right?

Here are some thoughts that might make your annual review a more positive experience:

• Keep records during the year. What have you done? What have people said about it? What did it mean to your org? The more data you have the easier it will be to create a year end review that shines.
• You might not be the one writing the review, but you can create something to send to your boss to help her remember what you've accomplished this year.
• Think about how you want to organize your review. You don't have to write things chronologically. Maybe you'd rather pull out some specific themes and follow them?
• Remember to prioritize your entries by impact too — 2nd, 3rd, 1st is a nice order to help keep the big wins 'top of mind'.
• Include comments from others. Quoting an email or notes from a on-on-one is a great way to reinforce the value that others see from your contribution.
• Work from established goals. Both yours and your organization's.
• Use last year's review and your records from the current year to hold personal retrospectives periodically. Make sure you're on track and excited to move forward.

And, who knows, a soundtrack couldn't hurt, right?

This is a book that I wish was on my son's required reading list.  Not that his code is hard to read (for someone in their first programming class), but that there are all kinds of bad habits that wouldn't need to be broken if he and his classmates spent some time learning what good code looks like before they started to write their own.



The Art of Readable Code from O'Reilly is a quick, easy read with a lot of useful ideas for new programmers.  It weighs in at 180 pages, but there's a lot of well used whitespace and a number of (mostly on topic) comic panels in those pages making it seem shorter.



Part one covers naming, code layout, and writing comments; parts two and three cover the meat of refactoring; and part four discusses testing and gives an example of applying the ideas in the book to a small coding project.



The book's examples are in C++, Python, Java, and Javascript.  I would have appreciated seeing some examples in other languages as well (haskell or scala might be good candidates), especially where that language might obviate or change the advice given.



Truth in advertising note, O'Reilly sent me a free copy of this book to review.