I was just talking about this idea with my wife. We're both now senior enough in our jobs that we're team/project leads (not managers, just technical leaders of stuff).
One of the projects I'm leading is a small R&D effort to see if a new technique will improve one of our core algorithms. And I have a very bright new junior programmer who has been with the company about 2 years and has a little post-college experience at another company, so he's not totally new.
When I give him work, he gets stuck (it's R&D after all), and blames the library or the API or things like that. It's like the "no there's not a bug in the compiler meme".
I'll take a good chunk of my day and pair with him to show him how to get around the problems, and it seems like he gets it, and then the next week when we sync up, he's back to blaming the tools.
My wife's opinion is that it just take a LONG time to learn that you're usually the one who's wrong, not the tools. And she pointed out that we both spent about 5 years in grad school. The biggest lesson of grad school is that you never know what's going on and that you need to figure out your tools, and that you're always the dumb one.
I've always been a little disappointed that I wasted so many prime earning years in grad school, but I think I agree with her here. Grad school is as close to the old "apprentice" model where you don't earn much (if any) money because you're primary goal is to learn the field and you really spend most of your time being in the way or annoying to your grad advisor. You don't bring much value in the time you're there. Much of that is learning how to deal with failure and working around that. (Edited to add: last week I found my archive of code that I wrote in grad school. I was surprised how little code I produced in those years and how I could now have solved the problem in about a week or so since I understand what tooling I now have at my disposal. But I did learn a ton in those years.)
I'm trying to figure out a way to get those lessons to my junior teammates (without making them feel as worthless as I did in grad school).
To bring this back to the topic, maybe Lamba school like boot camps are a problem just because the time is so compressed. You need time to keep learning the lesson that it's not the compiler, it's you. And then you can learn the problem solving of how do _I_ make this work.
Lots of self-taught from a young age people learn this, so it's not the grad school that's as important as the freedom to have time to learn (while not being on the hook to be providing value to someone who's paying you).
Not saying it's fair and I understand people need to support themselves, but I do think that the best problem solvers have put in the time and there's not real substitute for time.
Depends, I've come across plenty of people who act like what you say there, probably because it's a variant on the natural human tendency to cast blame on something besides ourselves, but... these days, things move so fast and we lean on so many amateur part-time projects, that bugs or shortcomings in the libraries etc. we use are not uncommon. The fine art is partially in knowing when it's extremely unlikely you hit a bug (gcc), vs. very likely (JS library with five stars on Github).
But more importantly, in digging in -- to me, that's a big part that's missing in leveling up the next generation -- like hey, there's a stack trace, let's go look at the lines of code in our source libraries and think about them instead of flailing around randomly like most people seem to.
Yeah, for learning that's good. But for novel research, not so much. I do a lot of what I always call "fast math on a computer" because that was a by product of me writing my own tools to solve problems in grad school. I didn't have numpy and only very limited BLAS optimizations existed at the time, so I had to write lots of low level stuff. But the actual novel work was pretty small on top of that.
In my grandparent post I mentioned that I could redo my PhD thesis in about a week of work. Much of that is that I know where the dead ends lie now. But a lot is also that I could just take advantage of numpy and I could just write everything in vector math now and not need to code up my own linear algebra stuff.
This is my take from this as well. I doubt that the developer in this story is literally thinking "these tools make it impossible for me to progress", I'm sure they're aware there's some way past whatever roadblock is there. So I'm not really sure what the complaint is about. Is the developer supposed to say "boo hoo I'm so stupid I'm stuck and don't know how to unstuck"? Does it make the situation any better if they blame themselves instead of the tools?
He's not going to recognize the pattern on his own, no matter how obvious it is to you. You will do him a disservice if you don't pull him aside one day and say, hey I noticed you have a blind spot, and I need to point it out to you because it's going to be a limiter for your career unless you learn to deal with it.
Yeah, you're right. This is the non-technical part of being a leader that I really struggle with. I'm much more comfortable "leading by example" and modelling behaviors and much less comfortable with how to frame a discussion like this.
Much of my company and field is full of nerds that are a bit outcast (including me). I hate the overuse of the term "bullying", but I'd say that most of the people I work with daily weren't the most loved kids in school.
So I don't want to add "boss thinks I'm doing a bad job" anxiety on someone by telling them that they're not matching my expectations. And If I put myself back to being 3 years or so out of college, I was probably behaving the same way, and maybe time to figure it out is what he needs.
My grad advisor was a real not nice guy, and even after all these years I still don't really like him. But he was what _I_ needed and my reaction to his pressure was to become a much better problem solver. I know I shouldn't act like him, but I haven't had many great role models in how to talk to someone about their performance.
I want to him to get the message that "he's smart and I know he'll figure it out" and not the message that "he's a bad employee and that he needs to start worrying about being let go in this bad job market"
Making people feel worthless isn't necessarily a bad approach. Break them down and then built them back up again into something better. But it can also fail catastrophically.
One of the projects I'm leading is a small R&D effort to see if a new technique will improve one of our core algorithms. And I have a very bright new junior programmer who has been with the company about 2 years and has a little post-college experience at another company, so he's not totally new.
When I give him work, he gets stuck (it's R&D after all), and blames the library or the API or things like that. It's like the "no there's not a bug in the compiler meme".
I'll take a good chunk of my day and pair with him to show him how to get around the problems, and it seems like he gets it, and then the next week when we sync up, he's back to blaming the tools.
My wife's opinion is that it just take a LONG time to learn that you're usually the one who's wrong, not the tools. And she pointed out that we both spent about 5 years in grad school. The biggest lesson of grad school is that you never know what's going on and that you need to figure out your tools, and that you're always the dumb one.
I've always been a little disappointed that I wasted so many prime earning years in grad school, but I think I agree with her here. Grad school is as close to the old "apprentice" model where you don't earn much (if any) money because you're primary goal is to learn the field and you really spend most of your time being in the way or annoying to your grad advisor. You don't bring much value in the time you're there. Much of that is learning how to deal with failure and working around that. (Edited to add: last week I found my archive of code that I wrote in grad school. I was surprised how little code I produced in those years and how I could now have solved the problem in about a week or so since I understand what tooling I now have at my disposal. But I did learn a ton in those years.)
I'm trying to figure out a way to get those lessons to my junior teammates (without making them feel as worthless as I did in grad school).
To bring this back to the topic, maybe Lamba school like boot camps are a problem just because the time is so compressed. You need time to keep learning the lesson that it's not the compiler, it's you. And then you can learn the problem solving of how do _I_ make this work.
Lots of self-taught from a young age people learn this, so it's not the grad school that's as important as the freedom to have time to learn (while not being on the hook to be providing value to someone who's paying you).
Not saying it's fair and I understand people need to support themselves, but I do think that the best problem solvers have put in the time and there's not real substitute for time.