The Ruby Freelancers Show 029 – Learning and Staying Current

Show Notes

Panel
Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp)
Eric Davis (twitter github blog)

Discussion
Requires Time and Effort
No Time vs. Not A Priority
Learning Takes Energy
Make a list of things to learn, set a schedule.
Learning GNU Emacs
Books vs. Screencasts
IRC
Mailing Lists
The Third Tribe
The Podcast Mastermind
Evan's Cat
The Main Modes of Learning
The Learning Pyramid

Picks
The Learning Pyramid (Eric)
Pragmatic Thinking and Learning (Eric)
Downcast (Eric)
Ruby Rogues - DHH (Eric)
Evening on Backbone.js/Views w/ Q&A with David Heinemeier Hansson (Eric)
ViewSonic VA2431WM (Chuck)
75 to 100mm VESA Converter Plates (Chuck)
LG Tone Bluetooth Headset (Chuck)
Go Groove Blue Sync Bluetooth Speaker (Chuck)

Transcript

 

[This episode is sponsored by Harvest. I use them to track time, track subcontractor’s time, and invoice clients. Their time tracking is really simple and easy to use. Invoicing includes a pay now function by credit card or
PayPal. You can sign up at getharvest.com. Use the code ‘RF’ to get 50% off your first month.] [Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.com]

CHUCK:

Hey everybody, and welcome to Episode 29 of the Ruby Freelancers Show. This week on our panel, we have Eric Davis.

ERIC:

Hello.

CHUCK:

I'm Charles Max Wood. And this week we are going to talk about Education and Training. The user voice topic says, “What do you do to keep learning and stay current?” And that’s something that I've always struggled with because it's always a time issue, right?

ERIC:

Yeah. It’s time and effort because realistically, there's an infinite number of technologies or things to learn, and you got to figure out like which ones are going to be worth your time, and which one is going to die off in a month.

CHUCK:

Yeah, that's the other thing that’s really rough for me is exactly that. Figuring out, not even which ones are going to die off, its which ones are the most relevant; which ones are going to have the biggest pay out to go and learn. So it's really hard, and since time is such a premium, I don’t know. Sometimes there are things that I know will pay off, but I still don’t go learn about them because I just don’t have time. And “don’t have time” is a lot of times is synonymous with “it's not a priority”.
And in some cases, that’s true too, it's just that there other things that I'm putting ahead of that.

ERIC:

It's time and it's also energy. Learning takes a lot of energy, and so if you just spend seven hours of your day doing heavy development for a client and you have an hour left, you might not have the energy to try and learn something new. And so it's like, “Okay, what can I do with the little energy that I have left?” And because training and learning new things typically doesn't have a short term pay off, like you're not going to like learn something today and be able to use it tomorrow for the most part, that it kind of gets pushed aside for the more short term fixes.

CHUCK:

Absolutely. And the other thing is that most of the time, I have some client work that I could work on right now, and so it's also hard sometimes to justify the, “Well, I could spend an hour earning money, or I can spend an hour about technology x.”

ERIC:

Yeah and having the client work when you are billing x amount per hour, versus the training and the education stuff, where it's an undetermined amount for that hour of time, it's kind of a hard pay off, especially if you need the money or you have to do something for the client. I can’t remember what it is, I think it's the problem of urgent task will always push out the important task.

CHUCK:

Yeah. And there are always plenty of those out there.

ERIC:

Yeah.

CHUCK:

How do you decide which topics or which technologies to learn about?

ERIC:

A while back, I started a list of like in this language, I wanna learn how to do these things, like I wanna learn how to use sockets, make HTTP connection, make a TCP connection, and all that stuff in whatever programing language I was learning. I would kind of like go through as like, “These are the exercises to do.” But recently because I've been so heavy in Ruby and getting into JavaScript, some of those, they just don’t really apply as much. They apply more for a general purpose languages.

And so now, kind of what I'm doing is I'm just taking a list of like interesting projects and technology that I see, and then I actually have a blog post that I just throw them in there right now. I have 55 different things in there, and it’s just kind of like JavaScript stuff, database stuff, Ruby stuff. And what I'm actually doing is once a week on Friday, I take one hour and take something off that list and just see what I can do and time boxes it, so I only spend an hour on it.

CHUCK:

That’s fair enough. I kind of like that idea where you just time box it. And then it's not, “Well, how many hours am I going to sink into this before I really get it. It’s I'm going to spend an hour learning about it and then I'm done.”

ERIC:

It's not just reading about it, so you can read about it and be like, “Oh, I think I understand this. I'm actually trying to write code.” I'll write a to-do list or like a running tracker or something , so that I can actually see all the bugs in all the areas. “Okay, if I'm going to use this, t his is what I'm going to run into.” And for example, I think two weeks ago, maybe three weeks ago, I try BackboneJS, because that’s all the rage right now. And I spent I think an hour and a half, and I got nowhere with it. And I actually gave up and the sad thing was I was really looking forward to Backbone. I was like, “This seems pretty cool. I can actually see where I could apply this in a couple of my projects.” Once I got in and started using it, I'm like, “Yeah, this wouldn’t work.” Like, what I thought the technology was, wasn’t actually what it was doing.

And so in Backbone’s case, I'm actually going to come back at another time and spend a little bit more in-depth stuff, because one hour wasn’t enough. But on the other hand, I try like KnockoutJS maybe a month or two months ago, and I spent like 40 minutes reading the docs, and then 15 minutes, I’ve built my app. So it's like, “Wow, this is crazy efficient. I could throw this into projects right now. I have a good enough summary.” So it's the time box seems nice, in that you know like this is the amount of time I'm going to invest, but at the same time, if you don’t give yourself enough time, you might not be able to dig in to something enough, to actually make a good, rational decision about it.

CHUCK:

Right. That makes sense. So how do you pick the topics? Is it just stuff that you’ve heard about?

ERIC:

It's just stuff I've heard about. I think when I originally did the list, I went on like GitHub’s… I don’t know if it was the most popular or the most watched, but I just went through their list and then in my to do list, I'd randomly put stuff like, “I heard about this gem called Fog that will create servers.“ That seems kind of cool, I might be able to use that. So I went through my to-do list and pull that out and put it into this post instead. I had it organized when I first started, and there's probably about a dozen different things that I’ve just kind of added on it at the end of like, “This is something cool that just was released last week. Let’s play with that in a few weeks.”

CHUCK:

Yeah, I kind of like that idea. I tend more toward if I run into something that will or would have solved the problem that I run into, then I just start playing with that. I'm not so much driven by, “Well, I'm going to try out this technology or this technique and then this other one.” I did make a list at one time, but I never looked at it again.

ERIC:

Yeah. I mean that’s one way. It's just in time like may be a client wants you to do something, or you know you are going to need to pick up like some client side MVC or something. And so you might like, “Okay, I'm going to take a bit of time and work on this and play with it,” but I've found for me like I would never set aside the time, and I would be like the last minute scrambling to figure it out. Or worse case, client wants it, I'm like, “Sorry, I don’t know what I'm doing with this. I'm not going to be able to build it that way. I have to go back to my old tools.” And so that’s why I set up these things where it's like every week, I do that. And I actually do the same thing for the business stuff too. I just don’t write about it, not that it's personal, it's very specific to my business and the idea is I'm trying them out.

CHUCK:

Right. That makes sense. So your approach generally is to just time box it, spend an hour or maybe an hour and a half on that technology. And when I'm trying to learn a new technology for example with this client that I've been working on full time, they are using Tmux, which I had never used before. I’ve heard about it. I've had people talk about it. I had it implied that I was not doing it right because I wasn’t using it, but I had never used it anywhere. And they are using Emacs on those machines and then we basically remote pair and we use Skype to go to meeting or something, so that we can transmit our voices and what have you, right?

Anyway, the deal is that I've never used them before. So I actually bought the Tmux book from the Pragmatic Programmers, and I already had an Emacs book that I had bought a while back because I wanted to learn about it, but I had never read it. And so I'm about 45% of the way through it. I'm on Kindle, so you can imagine it's percent and not page. About 45% of the way through the Emacs book. And then I'm probably when I finish with that, I'm probably going to pick up the Tmux book. And the nice thing about approaching things through a book, as opposed to… I mean, the video tutorials are nice and stuff, don’t get me wrong, but the book just kind of sat down and explained, “Okay, this is how Emacs thinks about these. This is what a buffer is. This is what a pane is, and this is what a frame is what a window is. And here are these commands, it allows you to do these things. And here's how you think about solving these different problems like copying and pasting and what not.”

Because it's different from Vim and that’s what I've been using, so the nice thing is, and I've never gotten kind of the philosophical explanation of Vim either. So it was really handy to be able to go, “Okay, this is the mindset behind how you use Emacs.” And so now when I'm doing things, I may not be able to remember the exact command, but I know the general principle, and so I can go look it up and then know that that’s where I wanna be. And this is the approach. This is exactly what I'm looking for. I just don't know the right keystrokes to make it happen. Does that make sense?

ERIC:

Yeah. For reference stuff and for stuff that like you need like a historical background on it, books are great for that because with the screencast, I mean for the most part, stuff has to keep moving in a screencast and the only way you can do that kind of background is if you go to like a slideshow and you have like a content, but then it's like you're just staring at a couple words or bullet points while the person is talking about stuff. And that’s why books are great for that.

My problem is I tend to read a lot, and not actually go back and apply it. So I actually have a Tmux book, I have a CoffeeScript book, I have a couple other ones. I haven’t read them. And so that’s why it's like I'd rather get in, dig in with the code. Like for Backbone, I'm going to be like, “Okay, I don’t understand this. I'm going back through a couple tutorials code. I'm going to kind of backfill a

lot of the stuff that I didn’t know and see if that foundation will help me actually make the code again. And so like it's just like I’m going to pass the weakness I have of reading something, and then not taking action by trying to take a lot of action upfront.

CHUCK:

Right. And that’s the payoff I think I'm getting out of reading these books at this point is because I'm actually using the tools day in and day out. But I agree like I read a book on Casandra, and it wasn’t until I started playing with it that it really made a difference, really kind of sunk in and I was like, “Okay, I get this.”

ERIC:

Mh-hm. And like you said, it's your experiencing Emacs and Tmux every day for those clients. And so you kind of need some of that background foundation, or you are going to get over your head because someone might do something in it and you don’t know was that Emacs doing it or was it Tmux? And so, having a foundation is going to help you and you can see like, “Oh, he's doing something in Emacs versus Tmux.” But it's the idea of if you don’t have a project that needs the tech, or if you're just really doing it just for research and trying to figure out like what's the gist of Casandra? I think getting it to the code or trying to do something with it is actually a lot better, a lot faster way to kind of fill around for it.

CHUCK:

I agree. So some of the other technologies that I'm going to be picking up for the same client are Redis and Apollo, which is a queuing server or queuing system. And you know, it's the same thing. It's getting in, seeing the code, seeing how it's being approached as part of the project, and then dealing with things on that level. But I almost feel like you have to build the project around it in order to really understand whatever technology you are after.

ERIC:

I think that's kind of learning in general. I mean, I can’t remember who said it, but it's like a pyramid of reading about it gives you a certain amount of skill. Listening to someone talk about it, like say a screencast, where it's just like presentations is going to give you a bit more skill, a little bit higher fidelity. Going and actually physically watching someone present on it is going to give you more sitting down with someone and just talking with them is going to give you even more. And then at the very, very highest fidelity, highest productivity is you are actually working with it. And I can’t remember what that’s called, but that’s kind of something to think about too, is like how much time do you have, how quickly do you need to do it, and could you try something that’s a little bit faster or more efficient.

CHUCK:

Absolutely. So are there other resources that you to go to for learning/training?

ERIC:

As far as ideas, like I said I try GitHub and I look on Twitter and someone might talk about a project, but as far as actually content, I mentioned it in the past. I used peep code. If you actually watch peep code’s RSS, that’s a good way of seeing what’s new tech, where it's not bleeding edge, but it's like kind of it's just out of bleeding edge. And so like EmberJS was out a little bit ago, so that’s like okay, it's off the bleeding edge. You can try to play with it. I look at Twitter for a blog posts, but that's kind of hit or miss, because a lot of people try to do bleeding edge stuff and write about it.

The other thing is most of the stuff I do is if I'm going to use a technology, it needs to be stable and work in production. So I don’t like playing with a lot of the bleeding edge things. I might take a little bit of a risk on it, but I try to stay away from it. For example with Chirk right now, I wanna use Redis. There's a couple of gems that use Redis for their storage, but I haven't used them in production. I don’t trust it quite yet even though it's actually reasonably stable.

And so I actually have a prototype that’s actually calling Redis with I think almost every page of you just doing something simple, but it's like catching exceptions and all that. So that way, I'm actually running it in production in a very, very limited scope for a bit. And so if it does blow up, it doesn’t actually affect the application. But I think I've been running it for a few months, I haven’t had a single issue or anything, and so now I actually have trust in Redis. So I can start working with it a bit more. But yeah, another thing to do is if people write mortems with projects or do presentations like, “This is what we used for app x,” like that’s sometimes good to get some ideas and not just about technology but like maybe different ways they are using and applying the technology.

CHUCK:

Yeah, that makes a lot of sense. I know that in a lot of cases, some of the technology that I pick up, I pick up at user groups, so I'll go to the user group and somebody will be talking about this technology or that technology, and I'll get involved there.

Another one that has also brought different technologies to my attention is conferences. So I'll go to a conference and I'll sit in on the talk and somebody is talking about how they use some API or some technology in a sort of a nonstandard way or something like that. And I've had that work out as well for the things that were really interesting.

I'm trying to think where else I hear them. I see a lot of them on Twitter. A lot of times too, I hear about it on Ruby Rogues, the guys they'll pick something that they like. And you know, I'll look into it when I'm really interested in it. But yeah, those are kind of the sources that I lean on to find stuff.

ERIC:

I don’t know if you’ve mentioned it, but also working with people. Like you said, you are using Tmux and Emacs now. If you weren’t on this project, you wouldn’t really be exposed to it enough to wanna do it. And so a couple of projects I've worked on, I've picked up new tools because the development teams are already using these tools. And so I came in, I was actually able to talk to someone to get answers, but I was also able to see their code that worked, and so I can compare that to like a tutorial code or this or that, and actually get an understanding really fast.

CHUCK:

Yeah, I have picked up a few things that way or picked it up because the client had other developers that had worked on a project, and we're already using it. And so you become familiar because you have to, which I guess is from other people to. But anyway, that definitely works out. So then once I run into those, typically I'll go find a book or a blog post or something. I like videos, but it seems like a lot of times, it's hard to find a good video that really explains things in the context that makes a difference to what you're trying to do with it. And some of the videos were just downright awful anyway. And so, I don’t know. It's hard sometimes to find a good resource, especially with some of these technologies that are moving ahead very quickly.

So for example, the book I read on Casandra was on Casandra version 0.6 I wanna say. And they are on version like 1.1 or 1.2. So the basic principles apply but they’ve added a ton more features that make a lot of things a lot easier. And so it's kind of tough to do that. You have to figure out where the people who are dealing with the newer versions are and then be willing to ask them questions too.

ERIC:

I've done this before, it's more intensive, and you have to know the language, but you can also just start code reading. I know JavaScript reasonably well, and so a while back, I wanted to like dig into prototype. And so I actually downloaded the prototype source, and I was reading through every file it had and figure out how they did stuff and picked up some interesting like, “Oh, that’s a cool little JavaScript technique.” And I feel like I have more experience with prototype now, even though I was using it for a while, going through the source I actually picked up like, “Wow, I don’t even know all these functions exists.” That’s something you can do especially if you're looking at a Ruby library, it might even be faster because typically the documentation is going to lag behind the source code, and books are going to be really far behind the documentation, videos, they still lag behind documentations, so if you wanna know what really Casandra can do, if you and read the source, that will tell you exactly.

CHUCK:

Yeah, one other good place for a lot of those stuff is to go and join the mailing list for the project. And in a lot of cases, especially on the apache projects, that’s the way they operate is they operate everything through their mailing list. And so if you go and join that user’s list or even the developers list or whatever project, a lot of times, you can get the insight that you need, to properly use and deploy whatever technology that you are interested in.

ERIC:

And the problem with mailing lists is that sometimes there are just a lot of noise on them especially like the user level mailing list. And so if you can find that there's like web archives of it, I've found sometimes it's good just using Google Search and use the site and that, but don’t actually give it a keyword. And half the time, Google will just give you everything that has index, but it will list it in like the most popular or the most relevant. And so you might be able to pick up some of the post that are like, this thread that’s fifty post long and that’s going to be one where you get a lot of information with very little time. So that’s another thing to do.

And I mean, if you have real time questions, chat and IRCs are typically great for open source stuff, because you can ask. You might have to wait a way couple of hours, but typically you'll get a reply. And I mean another thing is you can also just like play with it. Use Casandra like play with Casandra, do something, run into a problem and write a blog post about everything you did, or write an opinion of I think Casandra sucks for a reason. And if you do it kind of where it's like troll bait or whatever, someone might actually say, “Well, it sucks because you're using it wrong. This is how you should use it.” And that’s another way to learn is kind of be public about, “I'm trying to learn this thing. I don’t know what I'm doing. Can someone standup and help me?”

CHUCK:

Right. That definitely makes sense too. One thing that I've noticed with the IRC and chat channels is that in a lot of cases, you kind of have to wait for the handful of people that really get it to be there. I've gone in for different projects of different types, and actually had trouble because I'm asking the questions. And I either don’t get responded to or somebody responds and basically says, “I don’t know,” or that somebody’s response will be rude. And in other times, you get on, you ask the question and somebody is like, “Here, let me walk you through all of these,” and you get a handle on what's going on right away. I've kind of had mixed experiences with the chat rooms.

ERIC:

Yeah. When I was contributing to the RedMine project, I don’t know how many hundreds of thousands of installs RedMine has, but the chat channel, if you came in at Pacific Time, you'll probably catch me. If you came in kind of like work hours for Germany, you would catch some of the contributors from Germany. But if you came in any other time, it would be dead in there. And so there would be a bunch of people asking questions. And that was because there was only I think maybe 4-5 of us that really knew it good enough to kind of explain it. And so if you just on the off chance to get there at the right time, you’ll get no answer. You'll just get someone saying, “Hey, you are going to have to wait till someone shows up.”

It depends on people’s connections. Like if I wasn’t logged in, I wouldn’t see people’s questions and I might lose all their stuff and they might get bored and leave. But for the larger projects, typically IRC channels can’t. It's usually maintained pretty good. There's a couple of people, but that’s just something you have to watch for. And most of the time, you just kind of have to try. And if it doesn’t work, go to like a mailing list or something like that. IRC is hard because it's a one on one too, like you're taking the exact amount of time of the person you're asking your question. And so, I actually got burned out doing support that way, quite a bit.

CHUCK:

Yeah, I've also emailed the people that I know or Skype chatted with them and things like that. If you actually know somebody, a lot of times that's the best way to go, because you already have a relationship there and usually they are just pretty willing to just take a few minutes to help you out to understand as opposed to… and if you're working a with project with them, then they are really motivated to help you understand. But yeah, in other cases, it just depends. And RedMine, it seems like it doesn’t, I don’t know how large the development team is for RedMine, but it would make sense that if the team was relatively small, the number of contributors that it would be harder to line up a time where you can sure that one of them would be there.

ERIC:

And so before we forked it, we ended up just sending a lot of people to the forum and saying, “We'll help you, but you can post this in the forum, so when this comes up again, we can have someone else. We can just say, “Hey, go look at this link where we have all the documentation.”” Because it was like I said, four or five of us in it, and we were running out of time. I had to stay out of the channel because I actually couldn’t get any work done. I will be there answering questions for six hours out of the day.

But that’s kind of on the extreme end. I think if you do like kind of the low key of like reading the source, or just trying to play with the code, you can pretty much teach yourself most things. And for the most part, the documentations would be decent enough, that you are not going to able to run into big problems, unless it's like a bleeding edge system. But in that case, like you have to actually look at the source code and try to figure it out that way, debugging and all that.

CHUCK:

One other area of training… I think you’ve done more of this than I have is the online course. I know you did the 30x500. How's that worked out for you as far as the actual course?

ERIC:

I don’t think I've done any training for tech stuff, like Learn Rails or this or that. For business stuff, I

do a lot of it because it's a pretty efficient way of getting knowledge. And with business, it's you can’t just go look at the source code for business. You don’t have that hi fidelity thing you can do. And a lot of like the, “Oh, I'll just try and do and hack on business things and see what happens.” A lot of that, there's so many outside variables that you could do something completely right, but the environment is wrong so it gets screwed up. And so you might think that the technique was wrong. So that’s why I do a lot of courses.

I've done Amy Hoy’s 30x500. I did Michael Port who’s the author of Book Yourself Solid, which is a book I recommended. I did one of his courses. I think he stopped doing it, but it was kind of a group type training course where a bunch of different business thing. I've done a few about marketing, and then I think there's a few like smaller app sumo screencast with PDF type courses I've taken. And they are hit or miss. I mean, 30x500 worked really good. Michael Port’s thing, the content was good, but the course wasn’t organized that great, and I think that’s why he stopped it. And the app sumo stuff, that’s complete hit or miss. It depends on how good the presentations and stuff are.

But I think you have to figure out like how do you learn? I learn by reading and a little bit of doing. I don’t learn by listening and I don’t learn by just watching other people do stuff. And so the courses like 35x500 is good because Amy gives us PDFs to read, so I can read and get the background knowledge. And then there's homework and stuff where you actually go and do things. And so that’s why I've had the best retention with that class, whereas with Michael Port’s or whatever, there wasn’t as strong emphasis on homework, and so I would read and then I would actually take action, which was what I was talking about at the beginning of this where just read a bunch of stuff, get the knowledge but we don’t actually put it to use. So I think it's good if you can find a course and try it and see if it works for you. Like I know they don’t work for my life at all, like just her learning style is completely different. But for her going to conference or whatever, it's a great way for her to learn, but for me, it's really not that good.

CHUCK:

I'm not sure I've taken any online courses.

ERIC:

Would you consider mastermind groups or that kind of thing or online class?

CHUCK:

Not so much. So that’s another area I guess that you can consider for learning. And I definitely learn a lot of the mastermind group. But it's not like specific training. Now the Podcast Mastermind does have periodic, like sit down and do a webinar or whatever. And I'm also member of the Third Tribe and they have webinars on selling and web optimization and stuff like that.

ERIC:

But that’s not like the core offering of those groups, right?

CHUCK:

Right. The groups are actually as much about the interaction between the members is it is about the training sessions that they put together. And I don’t know if I would categorize them as course, but there are definitely some great ways to pick things up. I mean, the third time has a forum, the podcast mastermind has a forum. The podcast mastermind, we actually get together and discuss what's going on with each of us every month. So, there are definitely things there that are elements of successful learning. And I've had some of these guys explain or teach a certain aspect of life or business to me, but I didn’t go into them with the express purpose of learning a particular thing from them. Does that make sense?

ERIC:

Yeah. I've been in a couple mastermind groups and it's kind more of you get immersed in whatever the topic is about. It's about podcasting, or marketing. And you are just kind of supposed to like absorb and just pick up things, seemingly at random. It doesn’t have a lot of structure. Those can work really good. I've been in a few. I learned a lot, and a lot of it was from other people saying things like, they tried this and this is what happened from it. So I'm just wondering because some people consider those online classes or whatever. There's no structure around it or whatever.

CHUCK:

I have seen some of the masterminds where it is more structured in a sense that it's somebody, usually it's the person moderating will put together some kind of material for everybody to go over and learn. And the Podcast Mastermind, we do do that. We actually have to… we've been reading Tribes. I think it's the book that we've been doing lately. And so you read the book, you come, we discuss and things like that. But again, I mean you're not signing up and getting weekly or semiweekly or whatever training. So I don’t know. I kind of hesitate to call it training, but at the same time, it is a great way to learn. And in a lot of times, if you have the right kind of people in your mastermind group, then you can teach them things that they struggle with understanding, and they can teach you things that you struggle with understanding. And so it can be kind of that one on one training, almost like coaching, which is another thing that we probably have to talk about here in a minute.

ERIC:

I guess let’s talk about coaching then.

CHUCK:

Okay. So have you hired a coach before?

ERIC:

I haven’t hired a coach. I'm trying to think if I’ve hired any kind of advisors. I think the only thing I've ever done was I've been in I think two mastermind groups where it was, we're a couple of peers, I guess. And so someone might advise me on something that they know better than me, but like you said earlier, I would advise someone something that I know better than them, and so it's kind of a sharing. I haven’t had actually a coach or a consultant or anyone just say like, “I'm an expert at this topic. Eric, you should do this topic in this way.”

CHUCK:

So about a month or two before I went freelance, I hired a business coach, because I wanted to basically build my own business and gain some flexibility and stuff. My son was about to go to kindergarten, and I just wanted the flexibility of being able to be there for all of his little things and stuff. And so I hired a coach, and we were putting together a plan for me to build a product. We were still working out the details when I got laid off on what I should focus on and what I should do. And then it just worked out that I did freelancing. And so he advised me as best he could finding people to hire me and things like that. And coaching is kind of a subjective thing. Some coaches are really good for some people and not for others, and some coaches are really good for certain situations and not for others. And so it really just comes down to what you expect to get out of it, and whether or not you and your coach can effectively communicate to each other what those needs are, and what you need to do in order to move ahead.

ERIC:

It's like a partnership except it's not as strict. And if there's personality conflicts or if they are expert in an area that you don’t care anything about. It's not going to work. And I think that’s why there's a lot of different coaches and a lot of different types is the idea is you could find one in a specific special topic or you could find one like, “I like this person. They might not know everything, I wanna know but I like it.” I mean, I use my wife as a sounding board a lot. And so I'll say like, “Hey, I'm thinking about doing this and that.” And she's like, “Yeah, but you don’t even have time do the things you're already committed to.” So I think coaches are good for that, if you don’t have a

significant other who’s able to be objective enough, or if you just you need someone with more business experience or anything. So like coach or a consultant or even if you can find like an advisor or like a mentor. I think that could be really great even if they are not telling you, “You need to learn this,” or “You need to do this.”

CHUCK:

Yeah. You're just looking for somebody that has the expertise that you want to gain.

ERIC:

Yeah, or even just that they have kind of enough knowledge to know the general stuff about your business, but are able to kind of be blunt with you, and not worry about hurting your feelings.

CHUCK:

Right. Then they can offer some kind of unique insight, one way or the other, that will help you make the right decisions.

ERIC:

Yeah. And I mean half the time when I'm talking to my wife, by the time I said, “This is what I'm thinking about doing,” and started talking about what I'm going to do. I'm like I stop myself and I'm like, “Never mind. Don’t worry about that. I'm being stupid. I'm not thinking about this the right way.” And she wouldn’t even have to say anything, but you have to actually vocalize it and put your thoughts into words sometimes. And you can actually do this with programming too. I think it's called like the rubber duckie syndrome or something, where you have a rubber duckie, if you're trying to debug something, you try to talk through the rubber duck on your desk and tell them what you're doing, and usually by the time you finish telling the rubber duck, you’ve spotted your error and can move on. I actually have a black rubber duck that sits on my desk and he's been there for nine years, maybe ten years now.

CHUCK:

Oh, wow. Sounds like it's almost as old as Evan’s cat.

ERIC:

Yeah.

CHUCK:

And in a lot of cases with my coach, I did find that just in explaining things to him, it would immediately provide, I’d go, “Oh yeah, well I need to be doing this and that.” And so I would gain the insight myself, but the nice thing is I had this sounding board. And the other nice thing about it was that I had somebody who would hold me accountable. And when it comes to holding me accountable, my wife is really not good at that. She's a push over. And it's nice in some ways, but it's not useful in that sense. And you know, it's just a personality thing, but that means that I have to go find somebody else who would do that for me.

ERIC:

And not to get too far off topic, but a couple of years ago, I was looking trying to figure out like, “Okay, what am I doing with this?” And all these and that. And actually have to start looking at a couple people and made them my mentor without them actually knowing, so I will follow their blog, I'll follow them on Twitter, figure out everything they are saying, and try to build a mental model like, “This is how they think and how they make decisions.” And so I had one person I did that for kind of like business freelance and stuff. I had another person I did that for actually like technical Ruby stuff. And that actually worked really good.

And I figured out kind of like, “Okay, I'm thinking their perspectives like this,” and then overtime, I’ve kind of adopt that and integrate that into how I worked. And then maybe a couple of months, couple of years later, I’d actually say, “Okay, I'm going to move on. I'm going to pick a new mentor.” And so I kind of have a couple of lists like that where these are people that I follow very closely and see and try to analyze everything they do just to learn from what actions they are taking, what mistakes I've seen them doing and all that. And the nice thing is it doesn’t cost you anything other than time. And if someone is not really wanting to mentor anyone, you can still do this sort of thing to still learn from them.

CHUCK:

Yeah. I've heard a few people talk about things like that, especially where it's if you want to achieve things along the lines of what so and so has achieved, then you need to be doing the same kinds of things that they are doing. And you hear these examples like with millionaires. So they don’t do all exactly the same thing, but there are certain behaviors and mindsets that they all share in general. And so the idea is that if you want to be a millionaire, then you'll exhibit the same mindsets and behaviors to a certain degree, so that you can do what they do and approach money the way they approach money.

ERIC:

And to be honest, with business. Business isn’t that hard as far as concept wise. It's hard and the work is physically and mentally emotionally taxing, but business isn’t like building a compiler. I mean, people think compilers are easy. But you can try to find someone who’s gone before you and basically figure out exactly what they did and do exactly what they did, and you could pretty much expect to end up where they are. And I mean we've talked about it before, where we have a group where a bunch of us chat. And I've seen people come in, and kind of copy what someone else has done, and a year or maybe two years later, they are freelancing and doing the same thing in the same area as that previous person and as a previous person’s moved on to other areas. So it's like if you play video games like RPGs, it's like you level up and you are at a new level, all the person that you're following, they are leveling up too, so you can kind of follow along with them throughout the entire thing.

CHUCK:

That makes sense. So before we get to the picks, are there any other areas of learning or keeping current that we haven’t discussed?

ERIC:

Well, let’s see. We mentioned reading books, we mentioned working with people, and kind of talking to people like, “How do you use X?”, we mentioned conferences, coaching, doing online classes. Podcast, you can kind of listen to some of those and learn from that so, kind of on the audio side. I'm trying to think. Personally, one way that’s kind of common right now, you can learn something new is play a game that’s around it. So if you are trying to learn business, find a game that’s kind of a simulation of business and you can play that and that’s nice because it doesn’t drain you as much as sitting down and reading a thick business textbook.

CHUCK:

You can also turn some of the tasks that you have to do into games.

ERIC:

I haven’t been able to do it successfully. I mean, I don’t know. Maybe I'm doing it wrong or it just doesn’t work for me, but I always feel like it just doesn’t motivate me. It doesn’t actually work.

CHUCK:

I haven’t really had much success with it either, but I know other people, they are able to turn some of the things that they don’t like to do into something interesting or fun, and then they become better at it, more adept at it, and at the same time, they learn to enjoy it.

ERIC:

It's a valid strategy. I just haven't seen that work for me. Once again, it's very subjective. Different people are different, and all that stuff.

CHUCK:

Yeah, but I don’t know. But I mean, there are different membership sites that put out weekly videos. We kind of talked about learning from videos.

ERIC:

What are the main modes of learning? There's reading, listening, doing…

CHUCK:

Watching.

ERIC:

Watching, yeah. Stimulating all the senses, but you're not actually doing it. It's just there’s a lot of different things. I mean, I'll come back to figure out what you're best app learning wise, and what you enjoy because that might not be the same thing, and try that. And I mean I've found that learning period I was talking about earlier, so we'll put it in the show notes. It's a one page PDF. It's really simple. So that can help, but I think you just got to try different things. Keep your eyes open. And I mean for me, I've found time was a big problem, so I will actually schedule time. Some people might be able to do it adhoc and if that works for you, great.

CHUCK:

Makes sense. All right, let’s get to the picks. What are your picks?

ERIC:

I actually have quite a bit just because I've been thinking about the topic here. So I mentioned about learning pyramid, so I'll put a PDF in there. This basically shows the average retention rate for different ways of learning. And as the pyramid go, the bottom is the best, the one of the top is kind of the worst. And worst as in how good you are at remembering. Side note, the very worse one is a lecture, which is kind of how almost how 90% college is taught, which is kind of interesting.

CHUCK:

[Chuckles]

ERIC:

And I know that for a fact. So that’s one pick. The other one I just thought of is a book by the Pragmatics called Pragmatic Thinking and Learning. It’s a great book. I should actually read that again. It's published in 2008, so it's a couple of years old, but it's very, very good. There's a couple of tips in there that I've actually taken to heart and used, and I keep forgetting that that’s where I got it from. So that’s a great book.

And then recently, I don’t know if I've mentioned it, but I had an iMac where I was doing screencast and basically using iTunes to sync to iPad and my iPhone. And the hard drive, got the click of death a couple of weeks back and stopped booting. And it's an older iMac, so it's not really worth the repair and I looked at trying to swap the hard drive up, which basically entails taking the entire thing apart, taking the screen off. And I mean I'm surprised that it doesn’t include soldering.

CHUCK:

[Laughs]

ERIC:

Luckily my wife has a MacBook, and so we're probably going to be putting that in my office. I'm going to be using that for screencast, but iTunes as a software really sucks. And I have syncing it. And so what I'm actually starting doing is starting to get away from iTunes, get away from using a Mac for my phone and stuff. And recently, I bought an app called Downcast which is for podcast. I

guess it's called the Podcatcher. It would download and it could also stream podcast directly to your phone. The really nice thing and why I got it versus the other ones is you can use iCloud to sync your podcast descriptions, your settings, and what podcast you’ve listened to and where you are at between all your devices. So I can listen on my iPad, puase it, go upstairs, get my phone and start right where I've left off. So it's really nice. The only downside is I have like 8 gigs of podcast that I need to catch up on, which brings me to my next pick. I was listening to Ruby Rogues, which I don’t know who host it, but he seems pretty good at podcasting.

CHUCK:

[unintelligible]

ERIC:

I was listening to the one with DHH. It's a very, very good one. He drops his vocal bombs like normal, but I thought it was interesting because he actually pointed out a lot of the different discussion that’s going on between… I'm still trying to figure out the words for it, but the heavy, heavy object oriented pattern stuff, and then kind of I'm going to call it “pragmatic” but that’s not the best word for it. But the pragmatic just like get it done, worry about refactoring it and making it into the UML diagram later. So I thought that was interesting because there's actually a fair bit of conflict on the podcast itself in a good way.

And then my third pick is also of DHH talking about using BackboneJS in Basecamp Next. So it's a pretty long one. It's an hour and forty minute video, but I guess the most interesting point I got out of that was DHH kind of compared BackboneJS as dropping down into C when you have to, so they used Ruby and Rails everywhere they can, but when they need more responsiveness, they dropped down into C using Backbone. So I’d never thought about it that way. And that’s actually a

really nice way to kind of think about, “Okay, where should I go with the client side code versus actually just keeping it on the server.” That’s it. That’s five picks. That’s more than enough for me.

CHUCK:

I have a few picks as well. Since I’ve got this contract, we've been using Tmux as I said, and Tmux requires you to well, all of the people who connect to a Tmux session, what it does it resizes to the window size of the smallest person. Or if you have two people and one is constrained width wise, and the other is constrained height wise, it will go to the lowest common denominator. And so I had some not so large screens on my Mac pro. And so I got to order some new screens, and I'm pretty excited to put them up.

It's the ViewSonic VA2431WM, and I'll put a link to it on the show notes. I ordered two of them, and it turns out that I have two of the suspension arms that hold the monitor up, one which I got from some guy on some show that I do, and the other one I ordered off of Amazon. It was pretty cheap. And they both come with the VESA connector on the back or whatever. But those are both 75 millimeter VESA and the monitors require 100 millimeter VESA. So I've actually gotten some converter plates for them. They are like $25 a piece and that works out really well. So I'll put a link to those in the show notes as well.

And then finally, one thing that I picked up, and this is because my iPod’s headphone jack is going out, and so when I was in Chattanooga, I actually had to hold the iPod on my lap, and hold the headphone jack over to one side, so that it would play in both ears, and not switch to one area in another area and back and forth, while I was on the shuttle between Atlanta and Chattanooga.

So that didn’t work out, and so I got the LG tone headphones which is something that’s already been picked for the show. Evan picked them a while back. And that worked out real well. And then I got a Go Groove Blue Sync Bluetooth Speaker. And it just sits on my desk, it charges through USB. And so now I can listen to my iPod in my office. I just hit play and it just plays through the speaker, which is really nice.

Anyway, those are my picks. Just things that made my life a little bit better. And I don’t know if we really have any other announcements or anything, so we'll just wrap up the show and we'll catch you all next week.

ERIC:

Take care.

Album Art
The Ruby Freelancers Show 029 – Learning and Staying Current
0:00
50:38
Playback Speed: