I've been working as a software engineer for almost two years now but it's really only in the last six months-ish that I felt like I've gotten better at getting myself to learn things while at work that are beyond "what is the thing that I need to accomplish this immediate task in front of me." It turns out that the keys to success, at least for me, are:
- Get people to do something with me as a group.
- Don't try to start too many new things at once.
I'm not the kind of techy person that does a ton of techy side projects and experimentation and such outside of work. I have too many hobbies for that! I really like learning new things and I want to be better at my job, but it's best to try to get that done while at work, because I also like having pretty clear work and not-work parts to my life. Fortunately for me, I work with lots of people who are very similar in those regards, and with a little bit of corralling effort, I can take advantage of that to set up social pressure for getting myself to do things I already wanted to do.
For example, I'd heard from several mentors that doing technical book clubs was a good way to learn, so I pulled together some people at work who'd all been interested in reading Practical Object-Oriented Design in Ruby and booked a conference room for us to meet in for an hour, once a week, during the work day. At the first meeting, we discussed a bit about why we wanted to do a book club, what were some pitfalls we might fall into (participation dropping off, going so slowly that people lose interest, etc.) and set some ground rules with the focus of getting ourselves through the book in a timely fashion without being stressed about it. We're on our 5th book now, so that's been pretty successful!
One of our ground rules was that if at least two people were free to meet, the meeting would happen, even if other people had something that came up. The others could just catch up and join in again at the next meeting. We would also assign two facilitators who would commit to doing the entirety of the reading and try to bring code examples to the next meeting. This has dropped off a bit recently, but we got lots of great discussion and it really helped to be able to discuss how we might apply a technique or principle discussed in a book chapter to our actual work projects.
I think of myself as more of an instigator than an organizer; I try to set things up so it's not dependent on me to manage everything, like making calendar events modifiable by other people, writing down any setup instructions so someone can run the meeting even if I'm not there, etc. Mostly I invest energy into prodding things forward so we don't lose momentum. The meeting time and location doesn't really change, so we don't have to spend lots of time figuring out everyone's schedules, and we have a HipChat room for helping to coordinate as well as sharing related resources, like links to blog posts and conference talk videos, which are later added to the book club's wiki page. That page also hosts our ongoing list of potential books to choose for the next round, which we'll vote on to decide as a group. Sometimes it's more Ruby-focused stuff, so the non-Ruby people sit out until the next round, but that seems to work ok if we alternate it with more general architecture or design books.
At RailsConf this year, I got the idea from someone to start a another group at work, during our lunch hour, for watching all those conference talk videos that I bookmark but then never actually watch on my own. I set up a form for people to nominate conference talks (here's a copy of that form), and then the day before our weekly gathering, I pick 3 talks from that spreadsheet for people to vote on. I use youtube-dl to download the video in order to avoid any problems with streaming and Quicktime 7's A/V controls to sometimes increase the playback speed to fit in longer videos. This has worked well for people because all they have to do is show up with their lunch, and they're able to hang around a bit afterwards and discuss the content if they don't have meetings they have to get to.*
So those formats have worked really well for me! I did at one point try to set up a weekly "hey let's hack on things" session, but that was too structureless to get myself to get stuff done and I'd wind up just continuing on work projects. Basically,
Structure + Social Pressure = Success!
In general, I think it's important to not try to incorporate too many new avenues of learning all at once, so that you have some time to focus on making just one new thing into a habit before taking on the next thing. I usually have a mental (or written) shortlist of things I want to learn, so I think at the time of starting the POODR book club, the list was something like, "object-oriented programming, Ruby, and testing," all 3 of which were covered in doing that book club. Somewhere else I had a much longer list of all the things that people kept telling me I should learn, so I'd have to somewhere to at least just put that info, but if it didn't fit my top 3 priorities, I let myself disregard it for now so I wouldn't feel overwhelmed.
I think it's also helpful to try to be a bit organized about how you're going to learn these things, after you've decided on that shortlist of what you want to learn. For example, at one point, one of my three items was to get more comfortable with Angular, and I had two links to recommended tutorials saved for me to be able immediately get started on them when the free time came up, rather than having to spend a bunch of time searching around for where to get started and then feeling unsatisfied because I didn't actually do anything.
If you're somewhere that isn't as supportive of continuing education while on the job, or you're busy enough that it's really hard to carve out extra dedicated time to learn something new, there are a couple strategies that might help with that. One is learning how to make a case to your boss that your taking some time for reading a book or doing a tutorial will ultimately increase your effectiveness and how much you and your team can get done. Another is figuring out a way to shoehorn learning new techniques into projects that you're working on and having the patience to give yourself a bit extra leeway for when you're going to be a bit slower because you're forcing yourself to doing something in a new way that will ultimately be better than the get-it-done way you've tried so far.
Even at the most incremental level, every time you have to look something up to get a task done, you can probably take 5 minutes to read a bit more about that topic and take some notes for yourself so that next time you run into something similar, you know a little bit more than the last time you looked into that topic. Ever since Hackbright, I've kept a daily log of what I've been doing and links to particularly good blog posts or Stack Overflow items, with my one-sentence summary of what I want to remember for that content. I also keep a process doc where I stuff in git commands or keyboard shortcuts I want to remember (though again, I know I can't learn that many new things at once, so usually I have just one post-it note stuck to my monitor of the one new keyboard shortcut** I'm trying to learn).
So the overall strategy is:
Different things work for different people! My friend Katie writes awesome blog posts sharing tidbits she came across at work and then dove into more to come up with great examples for sharing that knowledge. Other people propose talks and learn about a topic if that talk is accepted at a conference.
Don't get down on yourself about all the other things you feel like you should or could be doing--of course you can always do more. However, I'm of the school of thought that guilt is mostly not a very useful emotion and it's better to keep putting one foot in front of the other, with the occasional lift of your head to look ahead and make sure you're progressing in the direction you want.
Even at the most incremental level, every time you have to look something up to get a task done, you can probably take 5 minutes to read a bit more about that topic and take some notes for yourself so that next time you run into something similar, you know a little bit more than the last time you looked into that topic. Ever since Hackbright, I've kept a daily log of what I've been doing and links to particularly good blog posts or Stack Overflow items, with my one-sentence summary of what I want to remember for that content. I also keep a process doc where I stuff in git commands or keyboard shortcuts I want to remember (though again, I know I can't learn that many new things at once, so usually I have just one post-it note stuck to my monitor of the one new keyboard shortcut** I'm trying to learn).
So the overall strategy is:
- Figure out the handful of things you want to learn next
- Figure out the barriers to you achieving those goals
- Experiment with different ways to help yourself overcome those barriers
Different things work for different people! My friend Katie writes awesome blog posts sharing tidbits she came across at work and then dove into more to come up with great examples for sharing that knowledge. Other people propose talks and learn about a topic if that talk is accepted at a conference.
Don't get down on yourself about all the other things you feel like you should or could be doing--of course you can always do more. However, I'm of the school of thought that guilt is mostly not a very useful emotion and it's better to keep putting one foot in front of the other, with the occasional lift of your head to look ahead and make sure you're progressing in the direction you want.
*We're pretty lucky at New Relic in that one of our VPs of engineering actually reached out to me with a bit of concern over us watching these talks over our lunch hour rather than feeling like we had the support to be doing this kind of continuing education alongside our work projects! We discussed it as a group and decided that watching these talks felt more like entertainment to us than work, and the time would allow for more people to be able to attend, with greater flexibility on topics not immediately relevant for work projects. But we've also had times when people played screencasts in the afternoon too, so timing can vary.
**If you're wanting to learn Gmail keyboard shortcuts in particular, these stickers are excellent for that! there used to be keyboard stickers that would help with those, but looks like they don't sell them anymore :(
