I agree 100% with learning on company time, but I suspect there's a better way than books, tutorials, courses, and videos.
I've talked to a lot of people over the years who have read the books and done the tutorials and courses. The most common problem they run into is that they finish all of that and then they say "What now?" The content they're consuming doesn't prepare them for the crux of being a developer: figuring out how to solve problems. And I think that makes sense. Interesting problems can't be turned into a series of steps without losing the complexity that makes them interesting in the first place.
Another approach to learning on company time is for managers and senior engineers to create opportunities for less experienced engineers to stretch themselves on real work.
Let's take a couple of the things you listed as examples:
Asynchrony, scheduling, threading, and concurrency
I worked on this codebase where we had a high-volume job that was single-threaded across the entire cluster. Out of 250 machines only one could run a single instance of this job at a time. Eventually the backlog of events the job was meant to consume got so backed up that some of the events had latencies over 30 minutes. The latency should be less than one second.
Now I know how to solve this problem because I've run into it before. But let's assume there is a less experienced engineer on my team who has expressed interest in learning more about concurrent programming. This is a great opportunity for learning. They'll need to learn what options their language has for concurrent programming and what sorts of failure conditions they should expect. They'll have to come up with multiple possible solutions and then compare and contrast them before deciding on the one they want to implement. They'll inevitably run into bugs that simply aren't covered in any tutorial on concurrency and they'll learn how to identify, debug, and fix them. And I'm right there with them the entire way to provide as much or as little support and structure as they need.
Threat modeling
One time I joined a company and found multiple security bugs in the first week as I was just poking around the code. It was pretty alarming that I found them so easily and so I suggested to my boss that a good way to familiarize myself with the system would be to do a semi-thorough security audit. Could I have done this myself? Absolutely. But instead I found another engineer that was interested in learning more about security and we did the work together.
For starters, I suggested they do a quick read of the OWASP top ten to get a feel for the kinds of stuff we're going to look for. The bugs I found were related to improperly handling user input, so we started there. They were able to navigate the code and I helped them identify bugs by simply telling them "there is a bug in this endpoint" and then answering their questions as they debugged. After we found the bugs we worked together to come up with solutions. The other engineer drove the conversation and I was just along for the ride to support their learning however they needed.
I believe the engineers in both of these stories learned much more from these limited, real-world projects than they could learn from any book or tutorial. Books and tutorials are great for mapping out a topic: understanding the vocabulary, the common problems and bounds of the topic, etc. But past that you have to do real work.
This is a really fair and thoughtful response. I would agree that it’s important to give junior engineers plenty of opportunities at bat to solve any problems they’re interested in or currently learning about. But just like study is no replacement for practical experience, practical experience is far more powerful when paired with study.
Typically I find that juniors are inundated with problems to solve and opportunities to prove themselves. It’s often overwhelming. Regularly setting aside time to study can help them gain a foothold and understand the way forward, rather than just scrambling to keep up.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree 100% with learning on company time, but I suspect there's a better way than books, tutorials, courses, and videos.
I've talked to a lot of people over the years who have read the books and done the tutorials and courses. The most common problem they run into is that they finish all of that and then they say "What now?" The content they're consuming doesn't prepare them for the crux of being a developer: figuring out how to solve problems. And I think that makes sense. Interesting problems can't be turned into a series of steps without losing the complexity that makes them interesting in the first place.
Another approach to learning on company time is for managers and senior engineers to create opportunities for less experienced engineers to stretch themselves on real work.
Let's take a couple of the things you listed as examples:
Asynchrony, scheduling, threading, and concurrency
I worked on this codebase where we had a high-volume job that was single-threaded across the entire cluster. Out of 250 machines only one could run a single instance of this job at a time. Eventually the backlog of events the job was meant to consume got so backed up that some of the events had latencies over 30 minutes. The latency should be less than one second.
Now I know how to solve this problem because I've run into it before. But let's assume there is a less experienced engineer on my team who has expressed interest in learning more about concurrent programming. This is a great opportunity for learning. They'll need to learn what options their language has for concurrent programming and what sorts of failure conditions they should expect. They'll have to come up with multiple possible solutions and then compare and contrast them before deciding on the one they want to implement. They'll inevitably run into bugs that simply aren't covered in any tutorial on concurrency and they'll learn how to identify, debug, and fix them. And I'm right there with them the entire way to provide as much or as little support and structure as they need.
Threat modeling
One time I joined a company and found multiple security bugs in the first week as I was just poking around the code. It was pretty alarming that I found them so easily and so I suggested to my boss that a good way to familiarize myself with the system would be to do a semi-thorough security audit. Could I have done this myself? Absolutely. But instead I found another engineer that was interested in learning more about security and we did the work together.
For starters, I suggested they do a quick read of the OWASP top ten to get a feel for the kinds of stuff we're going to look for. The bugs I found were related to improperly handling user input, so we started there. They were able to navigate the code and I helped them identify bugs by simply telling them "there is a bug in this endpoint" and then answering their questions as they debugged. After we found the bugs we worked together to come up with solutions. The other engineer drove the conversation and I was just along for the ride to support their learning however they needed.
I believe the engineers in both of these stories learned much more from these limited, real-world projects than they could learn from any book or tutorial. Books and tutorials are great for mapping out a topic: understanding the vocabulary, the common problems and bounds of the topic, etc. But past that you have to do real work.
This is a really fair and thoughtful response. I would agree that it’s important to give junior engineers plenty of opportunities at bat to solve any problems they’re interested in or currently learning about. But just like study is no replacement for practical experience, practical experience is far more powerful when paired with study.
Typically I find that juniors are inundated with problems to solve and opportunities to prove themselves. It’s often overwhelming. Regularly setting aside time to study can help them gain a foothold and understand the way forward, rather than just scrambling to keep up.