02:36 - Software Development and Reality Construction by Christiane Floyd

05:42 - Peter Naur: Programming as Theory Building  

07:55 - The Art of Empathy: A Complete Guide to Life's Most Essential Skill by Karla McLaren

13:14 - Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas

14:32 - ng-book 2

16:09 - Paper Reading Group 

19:58 - Mindset: The New Psychology of Success by Carol Dweck

20:29 - Cracking the Coding Interview, 6th Edition: 189 Programming Questions and Solutions by Gayle Laakmann McDowell

22:01 - Ruby Rogues Book Club Books Episodes

22:43 - Books to Learn When You’re Learning to Become a Software Developer

33:07 - Technical Programming Books

41:17 - Pramming and Business Books

Picks

Mark Manson: The Most Important Question of Your Life (Jessica)
Dan Luu: Normalization of Deviance in Software: How Completely Messed Up Practices Become Normal (Coraline)
The Noun Project (Avdi)
Lies My Teacher Told Me: Everything Your American History Textbook Got Wrong by James W. Loewen (Avdi)
CES (Chuck)
Bill Buxton: Avoiding the Big Crash (Jessica)

 

Call the episode 'Those other books besides POODR that you should read'.

[Laughs] Or we can even talk about POODR if we want.

Beyond POODR.

[Laughs] Beyond POODR.

[Laughs] Can we name the episode that?

[Laughs] Because I mean seriously, I think we've…

Yeah.

Somebody's recommended it like once a month since it came out, right?

Hey everybody and welcome to episode 243 of the Ruby Rogues Podcast. This week on our panel we have Coraline Ada Ehmke.

Coming to you from my blanket fort in Chicago.

Jessica Kerr.

Good morning.

Avdi Grimm.

Hello from Tennessee.

I'm Charles Max Wood from DevChat.tv. Quick reminder: go check out RubyRemoteConf.com. This week we're going to be talking about books. I think the implication was programming books.

But I don't think we really hard and fast set any kind of restriction. So, I'm really curious because Avdi and Jessica were talking about a book a few minutes ago. And I'm wondering what this book is and what it's about because it sounded interesting.

So, the book that we were talking about is one that I think I may have mentioned on the show before. But it's called 'Software Development and Reality Construction'. And it basically applies. It's really the proceedings of a conference sort of stitched together into a book of essays and papers with some introductory material interspersed throughout. And it comes from I think the early 90s. And basically it's all about, it's various perspectives on applying a hermeneutic philosophical perspective to software development. And I'm sure that's as clear as mud.

Yeah, hermeneutic means interpretive, right? Like hermeneutic says like how you interpret a text?

I do hermeneutic dancing. [Laughter]

Oh, there goes our family rating.

Hermeneutic dancing in a blanket fort.

Is there another way?

I'm just thinking about a bunch of theologians dancing now.

On a head of a pin?

[Laughs] That is where they would dance, isn't it?

Oh, man.

So, what are some of your favorite bits from the book, Avdi?

Yes. [Laughs] Actually that is the one book that my copy is upstairs right now. All the others are sitting next to me but that one's upstairs because I've been reading it upstairs. Gosh. I just read not too long ago, I read the parts about, some parts about learning theory. And…

The theory of learning or learning about theory?

[Chuckles] The theory of learning. And particularly aspects of how people learn by process and you can't, you just can't transfer knowledge to somebody else no matter how hard you try. And all of our successful attempts at teaching are about helping somebody to move through the same mental process from one point to a second point that we ourselves move through, and maybe helping them to do it more efficiently than we did. But all the learning that people do is that kind of process-oriented thing. It's not a thing where we take symbols and we take them from one person's head and then stamp those symbols into another person's head. That doesn't work.

Right. A lot of this book taught me about dialogue and the importance of dialogue which is different from conversation. Dialogue is more about… it's not just passing words back and forth. It is empathetically sort of acquiring part of the world model of the other person, like their mental model of how the world works. Or in our case when we're pair programming, how the program works. And sort of adopting their model for a while and seeing how it fits with yours and as a result we get to improve our own models of how the world and program works. Dialogue is distinct from conversation and I think that that's one reason pair programming is so crucial.

Mm. I totally want to do like a whole episode on this once we've all finished it. But I'm kind of curious about what other people are reading now.

Can we talk about 'Programming as Theory Building'? Because this is totally cheating. This is not a book. This is just a paper. And I'm pretty sure Avdi picked it on an earlier episode. But I've been dying to pick it, too.

I don't think I did.

Ah, dang it. So, I heard about it this summer and then didn't read it. But then this week…

I probably made reference to it on Twitter or something

Yeah. This week in paper reading group at work, we talked about 'Programming as Theory Building'. It's a 1985 paper by Peter Naur. And it basically says, “Look, we know programming isn't typing, okay? In fact, most of the output of programming is a mental model.” He calls it a theory of how a program works because that's what lets us change it. The program is malleable as long as it's alive in our heads, which fits beautiful with my whole socio-technical system theory of how we work. And I highly recommend this paper. It's not very long. And there's no math. It's not heavy at all. And it also really drives home how important pairing is, how documentation is not enough, how this information transfers from person to person and really there's no skipping that step.

It fits in, Jessica, with my definition of legacy software, which is software that you no longer have a mental model for.

Yes, that's the brutal stuff.

Exactly. And I've been doing some work on a book with Ernie Miller called 'The Compassionate Coder' which I'm super excited about. I just wrote a chapter on bringing new developers up to speed. And I touched on a lot of these things, like using Socratic Method for system discovery instead of the information transfer that Avdi was talking about. And I think it's also worth noting that when you're introducing someone to a new system, as part of their learning process that it's a

great opportunity to discover the WTFs in your codebase. Things that you sort of take for granted but when you see them from someone else's perspective you're like, “Yeah, why did I do it that way?” So, that onboarding can be a two-way learning experience, too.

Sweet. I can't wait to read it.

I'm pretty excited about it. It's my favorite book right now. [Chuckles]

That's awesome. We get to talk about it and it's not even out yet.

So, one of the things I'm reading for research purposes is a book called 'The Art of Empathy'. It's by a woman named Karla McLaren. And one of the ideas in it sparked a chapter and hopefully a talk on emotions as state machines. She describes emotions as neurological programs that have definite starting points and different outcomes depending on how you react to them, which I found really fascinating. Because I think that as developers we devalue emotions. We try to be… we have this ideal of the programmer as ultimately logical and rational an authority on a topic, when emotional intelligence is really valuable not only for our interpersonal relations but for understanding things like, how do I work fast? And how can I influence my mood to be productive? So, the concept of emotions as neurological programs I found really fascinating.

And so, I did a chapter mapping out major emotions as state machines. Identifying what triggers the emotion and identifying branches in the state machine that indicate different reactions to the emotions with different predictable outcomes.

CHUCK: Hmm.

Wow, that's really cool. Because once you can sort of document or diagram the system, once you have a mental model of how the system works, a mental model of your mentality, then you can influence it.

Exactly. And you can, instead of getting lost in the moment you can apply some rationality to the emotion you're experience and identify what's the cause of that. Did someone violate one of my boundaries? Do I feel challenged in my knowledge? Am I feeling really frustrated because I don't understand something? And knowing that there are multiple paths forward and knowing what the outcomes of those paths can be can lead us to be more healthy in our relationship with our emotions.

That's cool.

And the point the author is making is that once you understand your own emotions it makes it easier to understand the emotions of others, which makes you a better person and a better collaborator.

Hmm. Yeah, I find that helpful personally to, like when I feel something one, accept that I feel it. It is a valid emotion because it's there. And then I can go meta and say, “Alright, why do I feel this way? What do I want to do about it?”

Yeah. I'm pretty interested in manipulating emotions, too. Like personally, once I identify, okay I have this emotion, is it being helpful to me or is it a hindrance to me? And what can I do to influence it? I find that music really helps me a lot. And I have this funny story. A few years ago I was working at a startup and all the developers were in one room. And we all wore headphones as a result. And music is a pretty good indicator of the mood that I'm in. Like I'll listen to strong music when I'm coding and really in the zone. I'll listen to other music when I'm feeling depressed. I'll listen to other music when I'm feeling generally happy. So, I thought this was valuable information for people to have. So, I made a website that was called Threat Level Polka. And…

It basically plugged into the Last.fm API. Last.fm was a service that would track the music that you listen to. And I had an algorithm that would map the artist to a genre. And it displayed a Department of Homeland Security style threat level meter with different stops along the way for like, goth music: probably in a good mood, electronica: in the zone. And the highest thread level was polka because if my mood is super bad, that means I had to deploy the most happy bouncy music possible in an attempt to alter my mood. So, I encouraged my coworkers before interrupting me in my work to check ThreatLevelPolka.com to see…

The likely outcome of an interaction with me at any point in time.

Wow.

Wow, that's an observability right there.

Yeah, some transparency. It's sadly not up anymore. But it was pretty fun for a while.

Psst, don't bug Coraline.

Brave Combo is playing. Leave her alone.

All of my online lists of what does Avdi like have been permanently ruined by children's albums now.

Like all the services, you know, when they suggest things to me it's like happy bedtime tunes.

I'm pretty embarrassed sometimes. My daughter and I share an iTunes account and we have since she was a tween. And when I have guests over I'm like, “Hey, why don't you pick out some music from the Apple TV?” And they see some tween pop stars in the list. And I'm like, “It's not me, I swear.”

I don't listen to Carly Rae Jepsen. But I think the overall, my overall impression of this book 'The Art of Empathy' is that we don't do enough thinking especially as developers. We don't do enough thinking about our emotional states and how that influences our productivity. And just kind of being aware of them and being self-aware and then applying that same level of empathy to other people maybe in your pair situation or your coworkers or even your boss, can go a long way to making us more successful. And it's an area that I wish we would spend more time developing. We read a lot of texts that are intellectual in nature and make us better programmers. But I don't think we do enough work on being better human beings.

Alright. Another book?

Your turn, Chuck.

My turn? So, mine's a little more direct I guess than some of the examples that you all have given, mainly because you're talking about sort of the principles of software. And I've just been playing around with Elixir. And so, the book that I'm in the middle of right now is the Elixir book by Dave Thomas.

Oh, I've got that on my shelf and I've just barely cracked it.

1.2 just came out, eh?

That's a good one.

Fun stuff.

What are you enjoying about it, Chuck?

Mostly that it's a completely different approach. I mean there are definitely Ruby-isms in Elixir. But a lot of the core functional programming stuff is different. The immutability is definitely different.

Pattern-matching is awesome.

I love that, yeah.

And let me also mention that pattern-matching is awesome. I just, I love it. I love it. I think everything should have pattern-matching because I think it's cool.

I think it's great that instead of having conditionals in your code you just have a different arity for your method signature and change your logic accordingly.

Yeah.

But you still mean things the same way, so you get that cohesion.

Yeah. That's always fun, too. You know, you redefine it with a different arity and yeah, it works. So, I've just been playing with that. I think I might try and build an app in Phoenix and see where that goes. But for the most part that's something that I've been playing with.

I've also, the other book that I'm in the middle of is the Angular 2 book. And that's partially because I'm interested and partially because I have an Angular podcast. So, I mean between the two it's just been fun to just directly go after some of these technologies. And then the lessons that I'm learning out of it are definitely software lessons. And some of it's kind of meta. But it's, the books are directly about the technology.

What's the meta? What's the meta?

Well, the meta is where it's different from my own experience or where I struggle and then I learn something.

Do you go through and do the code while you're going through the book?

Yeah. If they have code samples, and most of these books do, I'll put the code samples into my text editor. And then I'll fiddle with them and see if I can make them break and figure out why they broke and things like that. So, I tend to go a little beyond just the typical, “Oh, I'm reading the book and doing the exercises.” But that also helps me figure out where the boundaries are and what the assumptions are.

I find it helpful to actually type out the code examples, too. I know a lot of books have code repos so you can sort of cut and paste. But especially for learning the semantics of a language I think developing some muscle memory around that's pretty helpful.

Yeah.

Completely agree.

In paper reading group that came up, that someone said that he couldn't understand a codebase in read-only mode.

Oh, yeah.

Nice, yeah.

That to really understand the code he had to like refactor it or write it himself or something. We need to not just look at the code. We have to interact with it in order to have a dialogue and really build the model in our heads.

Mmhmm.

Jessica, you mentioned a couple of times this paper reading group. Can you talk about that? And like… because I'd be interested in starting something like that at my work. But how does that work?

Sure. There's a Slack channel and [chuckles] called 'paper reading group'. And once a week we have a video call for 30, 45 minutes. And we decide ahead of time. Sometimes it's just that morning. Sometimes it's a whole week ahead of time, which paper we're going to read. We have a shared document where people throw suggestions. It could be issues on a Git repo. It could be, yeah… so, there's a list for suggestions and we agree upon one of these that we're going to read. And we've read papers about databases. We read the Raft consensus protocol one week.

And it's kind of awesome because you think, “Oh, I don't have time to read papers.” But we don't pick really long ones. And even if they are long, we don't read the whole thing. And it turns out not to take that long. And now we have like, “Well, this is work-related. We're building work relationships.” So, especially since a lot of us are remote and building work relationships is something we make a special effort toward. This sort of brings several pipes together, accomplishes several objectives. And it is kind of astonishing how much progress I feel from reading one paper a week and talking about it with people. Plus, I usually read them some portion of work time and lunch time.

How do you find the papers?

You know, there's…

On the internet.

Oh, not like…

How do you find your [corpus] of papers that you select from?

Like logistically? Oh you know, people bring them in from stuff other people have tweeted, or you could look at like Adrian Colyer's blog. He lists a lot of papers and sort of overviews them. We find ones sometimes that are kind of relevant to work and other times that are just sort of deep and interesting. And we kind of alternate between, “Oh, let's read about databases,” versus, “Let's read about Programming as Theory Building.”

You should post a link to that blog in the show notes.

Yes, I will. Right, so yeah. You could start up a paper reading group at work if you've got like, say three people who agree to… you don't technically have to read a paper. At least look at a paper and then we talk about it as a group for half an hour. Which, half an hour is a really short time. We only touch on the little bit of the paper but it's still, it's shared context, you know? And especially when we've got a lot of remote people, building that shared context is valuable.

We do a thing at healthfinch called 'stand down'. We do it Fridays at four o'clock. And it's a video chat for all of the remote developers to just hang out and talk about whatever. Its alternate title is 'learn you a thing' because we want to leave it open to technical discussions about theory and abstract ideas. So, I bet we can insert that paper reading exercise into our stand down pretty effectively. And that would be pretty cool. It's neat to see what other developers are interested in. And we have some pretty… we have some math geeks on the team who are really, they post papers sometimes to our engineering improvement slack channel. And I bet they would love to have conversations about some of these things.

Sweet. Oh, another great place to find papers would be Ines and Caitie McCaffrey did a keynote at QCon last year about papers. And they go through, I don't know, a dozen papers with little summaries. And that would be a great place to pick out some that you might find worth reading.

And I'll look for that link in the show notes.

Also if you're reading an interesting book and it has references in the text, go look those up. And a lot of times you'll find references to really interesting papers that way.

Mmhmm. Yeah, that reminds me. This isn't a coding book by any means but I recently read 'Mindset' by Carol Dweck. Isn't a coding book at all but just the way that she approaches mindset will definitely help you out as a programmer having a growth mindset. Go read the book if you want the details. But it basically outlines how to think about things and how to grow. And yeah, there are tons of interesting studies that she cited at the back of the book that you can go and look up on your own and see exactly what they did and how they came to the conclusions they did.

That's pretty cool. So, I do some mentoring. I mentor a couple of young women who are fairly early in their careers. And I had an idea that I have yet to implement. But a lot of places are still doing in technical interviews, they have like code challenges and a lot of them are sort of canonical examples, hopefully not Fizz Buzz. Hopefully something more creative than that. And the women that I mentor come from non-traditional backgrounds. So, not a CS background, not a strong grounding in algorithms and things like that. So, I know they have concerns about interviewing and it's a pretty intimidating process. So, I picked up a book called 'Cracking the Coding Interview' by Gayle McDowell. And it goes through commonly asked technical questions, things like “How do you work with binary trees?” and things like that.

So, I thought about using the examples in that book as learning opportunities where with my mentee we would take a session and work through one of the problems from the book to get a better understanding of some common idioms and common metaphors, some common tools and techniques. So, that book, I disagree with its premise that… well, I disagree with the tendency in our industry to favor whiteboarding and use arbitrary coding exercises. I don't think they're very effective screening tools. But they do exist. So, being prepared for them I think is kind of handy. And the book is pretty complete. It's huge. It's like 15,000 pages long and as big as my desk. But it has a lot of really cool stuff in it.

It's also worth noting that we've done a few book club books as part of the show. So, we did 'Smalltalk Best Practice Patterns'. We did 'Practical Object-Oriented Design in Ruby'. We did, I forget what the GOOS book stands for. 'Growing Object-Oriented Software Guided by Tests'. I think that's what it is.

Nailed it.

We did 'Patterns of Enterprise Application Architecture'. I'm trying to remember what they're called instead of all of the acronyms that I know.

That one's one of my favorites.

We also did 'Refactoring Ruby'. Both the last two were with Martin Fowler. One, because he wrote the book and the other because he's awesome. So, definitely worth checking those out if you're looking for books and looking for a review with this style of discussion on it.

I'm kind of curious. What were the seminal books for you when you were just learning to be a software developer?

Ooh, that's a great question. 'Peopleware', that was one.

Mm.

What's the one with, that starts with a tar pit?

'The Mythical Man-Month'?

Yes.

Thank goodness for the bookshelf cheat sheet.

So, what was the first one again?

'Peopleware'?

'Peopleware'. I don't think I've read that. You want to pitch it to me?

I don't remember it.

I remember it was important. But I couldn't tell you. Seriously, that was like at least 10 years ago.

Gotcha.

I still need to read that one. I haven't gotten to that one yet.

I've read 'The Mythical Man-Month'. I read it in college and…

Oh, wow.

It's funny because you read it in academia and that's definitely not how academia works. And they talk about it like, “This is how software teams work in the real world.”

And it turns out that he wrote that book like 20 or 30 years ago. And our software teams still have the problems that are outlined in that book.

Yeah. Well, and plus I'm not even sure that… there's a ton of… well, okay. In the part of the book that I've read there are a ton of great insights. But I'm not convinced that the way he describes how software teams ought to be is necessarily right for these days. I mean, he described this huge pantheon of different roles, each one occupied by a different person in the team. And very siloed.

Fair enough. But he does actually call out I think fairly accurately many of the problems that software teams run into and some of the broken thinking that goes around hiring people and building teams in the first place.

Oh yeah.

I think it's important too that that book was written during the waterfall era. And a lot of those concrete roles for software development… like I still deal with enterprise customers who have dedicated architects. And I'm like, “Wow, what is that?”

It's a guy that gets paid way too much to do way too little.

Something like that. There's another Steve McConnell book that found really helpful early in my career. This was my second time around as a developer. My first time around, I took the management route as I progressed. And ended up as a director and finally C-level executive. And as a side, I decided that I was happier being close to the code. So now, I'm happy being an individual contributor.

But a book that helped me back then was also by Steve McConnell called the 'Software Project Survival Guide'. And it was basically a set of project management techniques that were very practical, very useful, and with the result of like McConnell's experience in leading software development teams and software development projects. So, that is still on my bookshelf even though it's probably completely irrelevant today. But it was so helpful for me in figuring out how to organize effort of people on a team and how to focus on things that would actually result in working software.

And while we're talking about McConnell somebody should probably bring up 'Code Complete', which was a huge part of my early education on how to be a software engineer.

Oh, definitely.

I use the term engineer deliberately in reference to that particular book because I think it really does, it really does convey an engineering mindset.

Yeah, I have that one on my shelf. I have not read the whole thing though.

I read through it very early on in my career. I have not really gone through the second edition much, which is what I have on my shelf now.

Mm. I think there's a theme emerging with these older books, and I classify 'Code Complete' in there. That the problems that they call out are still problems.

Mmhmm.

And the heuristics and the suggestions of maybe you could solve it like this are usually still useful. But the prescriptions I think, we have updated a lot of those.

Yeah. Yeah, I mean you can even see that in two of the books that I read around the same time. 'Code Complete' was sort of on one end of the spectrum and then 'The Pragmatic Programmer' which came out just right around the time that I was reading these books… and it definitely…

I was going to mention that one as well.

It definitely had some… it does not have the breadth of 'Code Complete' but where they do overlap, I think there are definitely some different approaches there.

Yeah. I read 'The Pragmatic Programmer' and then within a year I also read 'Pragmatic Thinking and Learning' which his by Andy Hunt. And 'The Pragmatic Programmer' was just a great way of thinking about how do I become better? How do I become the kind of programmer I want to become? And 'Pragmatic Thinking and Learning' was, here's the process of actually learning how to do this stuff. And it helped me evaluate where I was and not feel bad about the struggles that I was having at the time. And mainly that just boiled down to, you're new. You're at level one or level two. And so, if you're having these problems, if you're having these struggles, it's normal. And here's how you go find people who can help you level up because they're a level or so ahead of you.

Right. There's another book in that category that I want to bring up, sort of the category of general how to be better at programming books that I read around the same time. But I don't see it referenced as much. I don't see it on as many bookshelves. It's called 'The Practice of Programming'. And it's kind of surprising to me that I don't see it a lot because it's by Brian Kernighan and Rob Pike who are of course Unix and C creators. And it's very much in the same vein as something like 'The Pragmatic Programmer' where it talks about, here are some guidelines that we've learned that make things easier.

And one of the ones that always stuck in my head was the concept of the numerology of errors or

of bugs where you look at whatever data you can collect from your bug and you look for interesting numbers, numbers that sort of ring a bell. And I remember applying that fairly early on in a situation where I had a memory leak and I ran some tooling on the program to find out where there were allocations that weren't then deallocated. And there were exactly one hundred allocations that weren't deallocated. And that was a bit of numerology where I could think, “Okay what is something that happens, when I run this test what is something that happens exactly 100 times?”

Mm, yeah.

It's interesting that you all seem to have read a lot of theory books early on. I was much more focused on hands-on learning. And so, I read a lot more technical books and less things about the art of software programming or how to be a better developer. I wonder how differently things would have turned out for me if I had read some of those theory books early on. But it's also interesting to me, Avdi. You were talking about you deliberately used the word engineer. And I wonder about the shift that we can see in the way that books are addressing our industry from the past 20 years or maybe even 15 or 10 years, from an engineering mindset to a developer or software developer or coder or programmer metaphor.

That is interesting, isn't it?

We borrow metaphors from other industries and we do so in a way that we kind of forget that they are just metaphors. We're not really engineers. But we're like engineers in some ways.

You mean like the way I have like a dozen books on my bookshelf that all have bridges on the cover?

Exactly.

So, it's interesting to see the shift in metaphors about what we do and why we do it and how we do it over time

Well, it's true. We have borrowed. I mean we've borrowed the term craftsmanship and we've borrowed all kinds of stuff. And I've heard the discussion. Are we engineers or are we craftsmen?

And the answer is sort of yes, both.

[Clears throat] Craftspeople.

Yes, thank you.

I'll accept that.

Metaphors are sneaky, too. I was reading one of the papers in 'Software Development and Reality Construction' today. And it actually reminded me that a menu is a metaphor. It reminded me. It was a paper about human/computer interaction. And there are these words that I don't even think of them. I mean obviously when I go to a restaurant I think of the menu as a restaurant menu. But I don't even think any more about the fact that those words were originally chosen in order to relate them to something that people had previous experience with.

I think the craziest one, I was just thinking about this the other day, is clipboard. Like, who has a clipboard with exactly one note on it, with exactly one thing that then you're going to remove and add to another document?

I know, right?

That's crazy.

That metaphor back when I was learning, you're right. That metaphor never worked for me. And menu was problematic too, because they never looked anything like the thing that… the menus in programs never looked anything like the thing that sprang to mind when I first thought of a menu back before I forgot it was a metaphor at all.

And now we have hamburger menus which are like, what even is that?

I have a clipboard program on my Mac so that it will remember hundreds of things instead of just one, which is ironically called ClipMenu.

It should be called a scrapbook, not a clipboard.

I know, right? Oh, missed chances.

Okay, okay. Alright, alright. Alright, enough about… oh, oh, speaking of metaphors. My favorite metaphor for programming I think, was it Sara Mei on Twitter? She was talking about how programming is like putting on a play. It's more like a dramatic performance with the people interacting and you write the script as you go. And then you iterate with each performance. And I love that one because of course when you put on a play, it matters who is doing it. Whereas the engineer metaphor very much says, “Anyone can do this if they follow these rules.” I much prefer the play metaphor because the interactions between the people obviously matters. And the fact that…

They're the most important thing in a play, in fact.

Yeah.

I do want to make it clear. I wasn't just reading high-minded theory books back when I was getting started. And some of the technical books I read do still stick with me, like the camel book, 'Programming Perl'.

Oh, yes.

Still possibly my favorite language book of all time.

That was a great one. I had this book. It was actually written by a friend of mine. I just tried to google it and I'm not coming up successfully. So, I may have the name wrong. But it was something like 'The CGI Handbook'. It was basically a cookbook for doing CGI scripts. And I used the hell out of that book. I probably tried every single recipe in it over the course of my first few years of development back when CGI was the way you built web applications and Perl was your usual language of choice. So, that book was like heavily thumbed through and heavily [scribbed] from.

Kind of in that same vein, one of my favorite books of collected recipes and bits of trivia is called 'Unix Power Tools' from O'Reilly. It has this huge…

Oh my god, I had that book.

It is this huge compendium of just decades’ worth of fun little command-line hacks for really learning how to use the power of the command line. And all the little tools that come with most Unix systems.

I wish they taught that at bootcamps because terminal usage is still mysterious to people. And they struggle typing RSpec, you know?

Yeah.

I used to have multiple copies of 'Unix in a Nutshell'.

Oh that's yeah, that's another essential one.

Yeah, one of my boyfriends when I was shortly out of college, I could tell he was legit because he had a copy of 'Unix in a Nutshell' on the floorboard of his car at all times. [Laughter]

For those Unix emergencies [inaudible].

That's right.

Sometimes you just don't have time for the man page.

Yeah. Plus a lot of those early O'Reilly books did a better job than the man pages. The man pages could be very technical but often they didn't give you a decent overview or like a decent, “Okay, here's the most basic invocation of this program. Now let's talk about what we just did there.”

Yeah, like providing real-world examples of how to use it instead of just, here are all the flags.

Right. Like, well I mean the classic man page format is there's a section for examples at the end, which is not how people learn. But it's a classic example of how computer people think you should organize information.

Well, the other thing is that if I'm looking at using a Unix command for something, usually I'm looking for, how do I do this on the Unix command line? Not, how do I use grep or sed to get whatever I need out of whatever?

Right. We want it by objective.

Yeah.

And they're describing the implementation.

Which is why 'Unix Power Tools' is awesome because it's definitely about objectives. Although albeit in a somewhat haphazard way.

I think it was one of the first O'Reilly books to not have an animal on the cover, too.

Oh, yeah. It's got a classic heavy-duty drill.

Yeah, an electric drill. I used to ask in the 90s as an interview question, if you were stranded on a dessert island and can only bring five books with you, how many of them would have animals on the cover? [Laughter]

Yeah, it's been kind of…

All of it, after I sticker them.

[Laughs] Nice.

That's sacrilege.

It's kind of sad in a way to think that my bookshelf has kind of progressed past that point. I don't know. I guess one of the things is that O'Reilly really didn't jump on Ruby early very much at all.

That's true.

And also not on some of the other stuff that's been coming out more recently.

Yeah.

But their cookbooks, they used to do a cookbook for just about anything. And that was another example of books that were very much objective-focused rather than first you had to know the name of the function and then it will tell you how to use it.

'Ruby Cookbook' was really helpful for me in the late 2000s when I started learning the language.

It's true.

Well, and when I was learning to program I was, well learning to program professionally I was learning Ruby. And that's when I started taking programming seriously. And so, you're talking about Perl books the same way I think about the Pickaxe book and 'Agile Web Development with Rails' and things like that.

Any more, I used so many different systems and tools that I can't read a book on all of those. I've got to settle for Stack Overflow. And it's frustrating because I don't feel like I know my tools deeply.

But reading an entire technical book these days, I don't know when the last time I did that was.

These days I only do it for learning a new language, pretty much, because I need that sort of stepby-step iterative building on what you just learned sort of approach that I don't find in online tutorials very often.

I do love that sense of grounding that I get when I go to a whole book on some technology

Yeah, it's beautiful to like have a decent mental model of it instead of just little pieces. I am super grateful that I have a solid grounding in Unix, like Avdi said, and SQL.

Oh, let's talk SQL books.

I don't have much to throw into that ring. I have some mostly that I haven't read yet. I'd love to hear other people's thoughts. But I will kick off with the one that I've at least marched my way partially through, which is 'SQL Queries for Mere Mortals'. Which from the parts that I've done already, is a great introduction to just, ground up introduction to SQL. It's the thing that I really wish I had had earlier on once I transitioned into web and enterprise programming.

I have 'The Art of SQL' which I think I just barely started but I've heard great things about.

I had an O'Reilly PostgreSQL book that was pretty darn good. It explained how it was organized, how it was all set up, and how to form your SQL queries. But I was pretty new when I read it, too. So, it may be a little bit basic, at least the parts that I was getting the most out of, for people who are a little more advanced.

In the end it doesn't… you could read a Postgres book. You could read a MySQL book. Back in the day I read about Oracle, because that's what we used. There's enough overlap in the language and how the databases work that any one of those will get you the foundation you need.

Right, and the quirks come in later. And you'll figure them out as you go.

I just realized I do also have the 'SQL Pocket Guide' from O'Reilly. And I think I recall getting a lot of mileage out of that for a while as I was stumbling my way through what is Active Record doing anyway? I also have a book called 'SQL Antipatterns' but I can't say anything for it because I haven't read it yet. Looks interesting, though.

I feel like we would be remiss if we did not mention 'Why's (Poignant) Guide to Ruby'.

Oh, yes.

Which I never actually read. I feel so bad.

What? I think that's the first Ruby book I ever read.

Chunky bacon.

Yes. It was so delightful because he covered things pretty in-depth but his writing style and his illustrations made the whole thing not feel like a struggle, not feel arduous at all. It was so approachable and it's something I still recommend to people who are new to programming, new to Ruby.

Well for me especially, since I was in a professional environment and I was very serious about becoming a very serious programmer, and reading that just made it so that it wasn't so heavy trying to learn some of the basic programming principles that I didn't get in college. And also, just pick up what I needed to know to do my job.

I wish that Why, well of course I wish that Why was still around publicly. But I wish that Why would write more, especially with the profusion of new languages we have today. I think 'Why's (Poignant) Guide to Elixir' would be awfully cool.

Yeah.

Yeah.

I don't know that Why would ever do that. Like, it always felt like he was more about… Ruby was Why's medium for expressing what he wanted to get across, rather than being, like okay, this is the technology of the day. I'm not sure how to say that better.

Wow. I want all my programs to be like that.

Yeah. [Chuckles]

Where the language is a medium but the message is not obscured by curly braces and [inaudible] types.

So, one thing that I'm curious about is if anyone has some books that are more from the borderland between programming and business that they particularly like.

I just finished 'The Hard Thing about Hard Things' by Ben Horowitz which is about being a CEO of a startup, really. That was very interesting. Kind of a look into how things get built in the companies that a lot of us work for, from startup to larger companies. Especially interesting points about hiring and how we do it wrong.

Yeah, and I've read a couple of company, I don't know, history profiles, whatever you call them. There's one on Pixar called 'Creativity, Inc.'. There's one on Google, 'In the Plex'. And they're pretty good. They focus a bit on the technology and a bit on the business. But I haven't read any that are sort of, here's how you do the thing like what Jessica said.

Ooh, ooh, ooh. 'Phoenix Project'. That is about DevOps and business but it's also fiction. So, it reads super-fast. That's a fun one.

Yeah, I've definitely heard good things about that one.

Yeah, you could read it in two days.

I think I have a copy of it here.

Mm.

But I haven't read it.

One of the books that comes to my mind, it's not about programming but it feels like it's particularly well applicable to the kind of programming career arc, is the book 'So Good They Can't Ignore You'. I felt that that had some high-quality insights.

What's it about?

It's about getting so good they can't ignore you. [Laughter]

I mean it's… I guess you could class it in the category of success books. It kind of, it examines the passion theory of success and of career. And basically tears it a new one.

Nice.

It's particularly concerned with the notion that you find the thing you love and then turn that into a career and it uses a lot of case studies to talk about how really more often people that succeed and eventually get into the point where they're doing something they love actually found the thing first and then they learned to love it. It talks about some examples like Steve Jobs who was often held up as a paragon of doing what he loved. But really, that doesn't seem evident at all in his total biography. It seems more like he went into technology because it was outside of his core spiritual interests but it was a way to make a quick buck. And then he loved to express, he learned to kind of express his passions through it. But that came later.

On the topic of career books, one that I read early on was 'The Passionate Programmer' by Chad Fowler. I really enjoyed that. I thought that was a very helpful book. The thing that I got out of it was that I needed to, again it was pretty early in my career and it just walked me through, here's what to expect from your job. Here's how to find a good job. Here's how to make good decisions about what you're learning. He talked about being on the bleeding edge versus supporting older technologies and why you may want to do one or the other, because people tend to get paid a lot to work either on the bleeding edge or on the older stuff that not a lot of people want to work on anymore. Because that engineer is harder to find. And just gave a lot of ways of thinking about your career and thinking about your job and moving forward. And I really, really enjoyed it.

And then the other book that I wanted to bring up was 'Soft Skills' by John Sonmez. And John wrote this book. It covers all kinds of stuff. And it's kind of a look at more than just your coding but also your life. And are you getting enough sleep and are you eating well and are you exercising as well as are you still learning to code better? And are you learning new languages and are you learning new algorithms, new paradigms? Are you doing the other things that make you a productive engineer?

I just thought of a book that was valuable to me in my career. It was 'The Rails Freelancing Handbook' by Mike Gunderloy.

I never even heard of that one.

It's an eBook and it's been around for a long time. And well, relatively long. Obviously since Rails. But it's not long. It's, according to this page it's 68 pages long. But it's a great… I think most programmers, probably a lot of programmers anyway, hit the point where they want to try freelancing. And it was a cool book because it just kind of ran through very quickly and without a lot of fluff ran through, here are the things that you need to think about. Here's a real basic idea of how to think about how much money you need to make in order to make it work. And here are the things you need to think about with regard to business insurance and covering you liabilities and stuff like that. So, there are various books out there for thinking about a freelancing career and even specifically a software freelancing career. But this was cool because it was highly focused on what I was, where I was going. And short.

So, another book that unfortunately is really useful. You may or may not know, it's very difficult to be a woman on the internet and it's very difficult to be a woman in tech. And there's a book by Violet Blue called 'The Smart Girl's Guide to Privacy: Practical Tips for Staying Safe Online'. And unfortunately I got doxxed this year which means that as a result of someone violently disagreeing with my stated opinions, they decided the correct response would be to publish my private information online including my home address. So, the book has a chapter on how to prevent doxxing and what to do once you have been doxxed. And some basic safety and survival tips for trying to keep as much of your information private as possible, preventing identity theft. One of the common problems that we run into in general with people on the internet, but in particular if you happen to be a woman in tech. So, that's a really good book and a good practical survival guide for being a person with an opinion online.

I might have to share that with a few people I know.

Yeah, it's unfortunate that a book like that has to exist. But I'm glad that it does.

Yeah, those things shouldn't happen. But they do.

I just remembered another book, not related to that. But I remember another book I really liked. And I want to say it before I forgot about it. 'Practices of an Agile Developer'. That's definitely in the category of just getting better at programming books. But I just wanted to nip that one. It's good.

Alright. Well, I think we've given everyone their reading list for the next few years. Let's go ahead and get to the picks.

Sure.

Jessica, what are your picks?

Alright. So, I wanted to pick this blog post because it's not a book. So, I couldn't pick it earlier. But it totally relates to what we were talking about. This blog post is called 'The Most Important Question' and it is about instead of thinking of a goal that you would like to achieve, think of what you're willing to do in order to achieve happiness. It's about, you're never going to get to a goal unless you love the process of getting there. This is really important to me. For instance, like speaking. Why do I speak at conferences? Why am I good at it? Well, a lot of it relates to I love the whole process. I love thinking of topics, I love writing abstracts, and I love doing talk prep. And because of that, I can achieve all these great speaking activities. But there are other goals like answer all my email that I just don't love the process. And I need to just let go of those and enjoy the fantasy of inbox zero, if that makes me happy.

But Avdi, you mentioned Steve Jobs as finding a useful thing and then learning to love it. So, that's another option, is that we can learn to love our job that also happens to make us money. But focusing on the process not the goal is so important and I really like this blog post and I will put a link to it in the show notes.

Alright. Coraline, what are your picks?

I have one pick today. It is a rambly blog post by a guy named Dan Luu who I believe works at Microsoft. And it is a reaction to a paper actually by another person called John Banja called 'The Normalization of Deviance in Healthcare Delivery'. So, the basic premise of the original paper and the response is that humans are really bad at taking time to do things that are well understood to reduce risk to prevent rare but catastrophic events. We rationalize taking shortcuts and believe that they're the right and reasonable things to do very often. So, the term for that phenomenon is called the normalization of deviance. And it's been pretty well studied in a number of contexts including healthcare, aviation, mechanical engineering, aerospace, civil engineering. But we don't often see it discussed in terms of software.

So, some examples of normalization of deviance is turning off or ignoring notifications because we get too many of them. We have Monit at my work and I know that I don't read Monit emails because I get 2,000 of them during the day. Ignoring flickering failures in our tests. It's like, “Oh, it's just a test problem. It's not actually indicating a problem with the code. It's just a badly written test and just run the test suite again and it'll go away.” Or my favorite, not going to a staging environment because you're change is so simple that nothing could possibly go wrong.

[Laughs] I've never had that bite me.

No.

So, he goes into some tips for preventing normalization of deviance like paying attention to weak signals. Because weak signals are probably where the most important information is coming from. Resisting the urge to be unrealistically optimistic, learning how to conduct emotionally uncomfortable conversations, feeling safe and speaking up and realizing that oversight and monitoring although tedious are never-ending tasks. So, it's a really interesting blog post and he links to the paper as well, so you can actually go and read the paper. And you can extract some useful information even though the context of that paper is healthcare. So, that's my pick.

Alright. Avdi, what are your picks?

So, here's a little thing that was handy to me the other day. There's a website called The Noun Project which…

Yes, I use that for so many of my talks.

It's great. They basically set out to just collect simple black and white vector graphic type illustrations of all of the things. Like, any noun you can think of, any concept you can think of. I was reminded of this. I'd known about it before but I was reminded of it the other day when I was making some morning checklists for my kids so that I wouldn't have to micromanage their mornings. And not all of them are old enough to be readers or fluent readers. And so, I wanted to adorn the items with some representative icons. And I was, in my search I was reminded of The Noun Project and I was able to find icons for breakfast and clothes and toothbrush and things like that. So, that's a great resource.

And they're all free to use with attribution, which is really cool.

Yeah. Yeah, I mean you can license them for commercial use. But otherwise you can just use them. They're all Creative Commons.

Wow, that looks great for Slack emoji.

I was looking for one for truth the other day.

Oh boy.

And apparently The Noun Project has a pretty decent one of an elephant under truth.

Interesting. [Chuckles]

Best of all they're not animated. That's my biggest…

You know, it is true…

My biggest problem with Slack is the animated GIFs.

I have to say an elephant has never lied to me.

I guess for my other pick, I will just pick the latest book that I finished on Audible which was 'Lies My Teacher Told Me' which looks at some of the myths that are reiterated over and over again in textbooks even though in history textbooks for high schoolers, even though the history profession as a whole has long ago discarded them. But for various… it kind of dives into the various reasons that these textbooks are just like a world of their own that exists apart from the profession of history. So yeah, it's a good book.

Very cool. I've got a couple of picks. The first one, I went down last week to CES. And I just want to talk briefly about what I saw there because it was really fascinating. Internet of Things is taking off. At least there were a zillion companies there showing off their Internet of Things things. Under Armour had smart shirts and pants and socks and shoes. And there were a bunch of other companies that had different chips that went into shoes or that after-market people could buy and put into their shoes and it would track all kinds of information about how they moved and where they moved and what they moved. And really, really fascinating. There was another entire section of the show floor that was dedicated to 3D printers, which was also very fun. And robots. Robots are coming up and a lot of people are doing interesting things with them. I didn't make it over to the Las Vegas Convention Center because I only had one day to look. But there are a lot of other things coming up in healthcare and stuff like that, that are just, I think they're just going to kind of blow the lid off of where we are currently. So, I just wanted to pick those and just talk briefly about that.

If you get a chance to go to CES, I think you should at least once. Bring some comfortable walking shoes because you're going to do a lot of it. And yeah, make sure that you go and kind of… you don't have to stop at every single booth. Just walk through and if something catches your eye, check it out. There were also a lot of home automation systems. And a lot of these, I'd stop and I'd talk to them and I'd say, “Hey look. I talk to a lot of programmers. Do you have an API that people can plug into, either building web or mobile apps?” And a lot of them did. So, I think our profession is going to delve into an entirely new classification of applications here within the next four or five years. Typically the stuff you see at CES, they're going to try and release it this year. But the early adopters are the ones that pick those up and then it kind of moves ahead from there. So, I don't know if I expect all that stuff to come out within the next few years.

Anyway, super awesome. Jessica chimed in, in the chat room, and said she has something to add. So, go ahead.

Oh, okay. So, there was another thing that I was going to pick but I didn't. But now it's totally related to that so I'm going to pick it. This is Bill Buxton's keynote from QCon in 2015, QCon San Francisco. And Bill Buxton works at Microsoft Research. And he is a world expert in user experience. The keynote was really fascinating. It's about how we're going to build the apps of the future to avoid the complexity apocalypse. And a lot of it involves integration and APIs. And also, thinking about the edges, the small screen and the big screen. What does that mean for the middle screen? It's an entertaining talk and very insightful. So, it just came out on video last week.

Recommend that. The end.

That sounds fascinating. Alright. Well, I think that's all we've got. So, thank you all for being here and we'll catch everyone next week.