learning at work
src: Learning at work - 2022-03-27
Abstract
Some tips to learn:
- don’t learn programming language/framework outside of work
- choose projects I think I’ll learn from
- watch more senior people operate
- read every pull requests
- read the source code
- follow up on bugs I couldn’t figure out
- use your commute to listen to podcasts, read papers, articles…
- take the time at work to learn
I asked on Twitter a while back “how do you invest in you own learning?” (this tweet). Some common things people replied with:
- Read blog posts
- Go to conferences
- Read books
- Watch talks while washing the dishes
- Build side projects using the technologies you want to learn
These things all totally work. I see that it’s pretty common to spend time outside of work working on your career development and learning new skills, and it’s certainly something I’ve done a lot.
But I know some great programmers who don’t program outside of work at all! So I got to thinking – what if you want to become awesome, but don’t want to spend a lot of time basically doing extra work after hours?
Here are some things me & people on twitter came up with. Everything in here is stuff I can do during my workday.
Don’t learn programming languages/frameworks outside of work
This one is kind of negative but I think it’s useful! My view about learning programming languages is:
- I know a few languages reasonably well (python, scala, ruby)
- Learning a new programming language well takes a fair amount of time
- I don’t feel like spending my free time on it
Right now at work I’m working a bit in Go! That is interesting and I’m happy to be doing it. But it is not so fun that I feel like spending a lot of my personal time on it. And I don’t really think it’s necessary, I learn languages by writing them, reading other people’s code to learn about conventions, and having my code reviewed. I can just do all of those things at work!
To be clear, I don’t think it’s bad to learn programming languages outside of work. I just don’t really do it.
Choose projects I think I’ll learn from
Some of the things I’ve learned about in the last 3 years at stripe:
- Scala/Ruby/Go
- hadoop/mapreduce/scalding
- How to work with java concurrency libraries, how to profile a java program
- A ton about how various AWS services work
- A lot about machine learning
- How networking / CDNs / TLS work
- docker / containers / rkt / kubernetes
- Service discovery / DNS / jenkins
and a bunch more things.
As an small example of choosing something to work on that I wanted to learn from – once I was using a program at work that wasn’t parallelizing its work well and it was a problem. I could have asked the people who wrote it to figure out the program but I thought – well, I’m interested in learning about concurrent programming, I can probably do this! So I learned a bit about how to use thread pools in Java!
I only worked on that for a few days but I learned new things!
Right now I am working on Kubernetes which I didn’t really pick for its learning opportunities, but I am learning quite a few things about distributed systems and Go by working with it and I’m happy about that.
I think it’s silly when people are like “hey, we work with X technologies, you need to have experience with them to work here”. Right now I spend a lot of time with networking/puppet/kubernetes/docker/AWS and I had never worked with any of those things before this job.
Watch more senior people operate
When someone is doing work I really admire, I’ll watch how they do it and then try to emulate them / ask them for advice. For example! When cory joined I noticed that, when introducing new technology, he would
- find another team that had a related problem that needed solving
- Work with them to make sure the technology actually worked to solve their problem!
Right now I am working on a newish project, and I’ve been careful about remembering who exactly I expect it to help & how, and I think that’s made the work go a lot better.
Read every pull request
Two quotes I loved from this thread were:
I’m on a small team so I read & reread every pull request that comes in until I understand the problem & solution fully
and
I did the same! And I stalked checkins to see how people solved various problems
I don’t actually read every single pull request on my team. But I do find it useful to pick a few areas I want to keep learning about, and keep track over time of the work people are doing in that area.
I definitely can’t always do this – for example I used to work on machine learning and while in theory I’d like to keep track of what people are up to there because I find it really interesting, in practice it’s too much for me to pay attention to. But I do try to pay attention to things that are closer to me (like some of the networking team’s work!)
Read the source code
Reading source of what I use is a big one for me. Understand what it does internally but mainly why it does it a certain way.
I think this is a fantastic tip and super important!! A lot of systems aren’t really that well documented and you can’t learn how they work without reading their source code.
Follow up on bugs I couldn’t figure out
Sometimes I see a bug that I can’t figure out how to fix. And then later, sometimes somebody else will figure out the answer! When that happens, I like to really take the time to understand what the answer was and how they figured it out!
For example recently there was a networking issue that I didn’t manage to debug and that somebody else just figured out last week. Thinking about it now, I understand what the bug was, but I’m not 100% sure what tools they used to get the information they needed to debug it. When I get back to work I need to make sure I go find that out, so that next time I will be better equipped!
Jessica Kerr commented
Whenever I have to look something up for troubleshooting, I go a little deeper or broader than strictly necessary.
which I think is a great philosophy :) :) (it’s not good to go too far down every rabbit hole, but consistently reaching a little further than I have to pays dividends for sure)
I also liked this answer:
Sometimes I’ll just dig into a problem that’s work-related but not really within my actual duties and see if I can get somewhere.
Use your commute
I don’t have a commute but a lot of people mentioned using their commute time to listen to podcasts / read papers / read interesting articles. I think this seems like an awesome way to keep up with things you’re interested in!
Take the time at work to learn
Someone on Twitter said “I wish I could take 1 hour a day to learn”. My view is that it’s my job to take time out of my workday to learn things. Like right now I’m using Kubernetes at work, it’s a complicated system that takes a long time to understand, and I spend time reading about it at work. For instance, when we were starting out I spun up a test cluster just to poke around and try to understand how container networking works. I also make progress on our projects at the same time!
This is probably a bit easier for me because I work remote so nobody really knows what I’m doing hour-by-hour anyway, People just care about what I’m getting done overall.
I actually think I would probably be more productive if I took a little more time to read in advance. Like I just read Kelsey Hightower’s “learn kubernetes the hard way” document, it didn’t take that long, and it had one really good idea about how to set up a cluster that would have saved me some time.
Some people take this idea even farther! For example, my friend Dan has mentioned a few times that he likes to read technical books at work. I originally found this kind of surprising but it makes sense – there are some books that are relevant to my work, and there’s no reason really why I shouldn’t read them at work.