I took a bootcamp. One day and another student and I were working on something and a third member of our group (who had other issues) was really frustrated and took it out on us and then went to the teacher.
She told the teacher "they just get it and I don't".
But in truth the other student and I were not "just getting it", we were failing frequently, we had made no more progress on what was a fairly elementary task than she did. We just kept trying ... kept our hands on the keyboard and came up with new things to try. We were no less frustrated too.
Now there's more to it than just typing like coming up with those ideas / thinking it through, but the grit to do that is not something many people have just to start.
Amusingly that seems to be a problem with seasoned programmers too. I work with some good guys who do their job well enough, but man they hit a little cognitive dissonance and they just fall apart. I'm not better and very much not smarter, I just keep thinking about the problem and keep trying. A troubleshooting mindset, curiosity, and will to keep going is hard to really test for and give to someone.
You underscore the same thing I noticed as well: To have a decent career as a software engineer you need to be a tenacious problem solver. Even the not-so-great devs are tenacious.
There are tons of smart, hard-working people who have a mentality of "You should be able to do everything correctly and have it work correctly the first time, or maybe on the second try with some minor adjustments". And I think these people will find no joy in being a software developer and typically don't survive bootcamps.
Software engineering is like digging a hole, where every time you strike your shovel down you either hit a huge boulder or a giant lead lined pipe no one told you was down there. It would take some kind of a mental disability or achieving a state of enlightenment to not be frustrated by being constantly blocked and held down when you want to run, which is the real definition of this job.
I think you’ve also gotta be comfortable being in a pretty dark place a lot of the time.
It’s like being a plumber if your tools did surprising things or simply broke and required repair regularly, you had to learn totally new (and usually not any better) tools every year or two, and you did the actual work with a crappy remote-control robot, mostly crammed into dark spaces, with no schematics or plan or even ability to personally see the outline of the general area you’re working in and lights that only illuminate about 2 feet ahead.
Lots of the time all your shit you need to do the other shit is broken or is lying to you, and you’re also in some awful little mess that you can’t be sure there’s any real way out of because you can’t goddamn see anything.
“Ok time for standup!” now try not to slip and say “fuck everything, I hate life, all of this is bullshit and I’m pretty sure we don’t even need to be doing it. No blockers.” Keep on your mask that presents you as employably-stable.
It kinda fucking sucks. I get why people don’t want to do it.
[edit] oh and it’s that plus all the usual offices-suck dehumanizing , quietly degrading, pointless-feeling, politically- and ethically-nasty (cf Moral Mazes), boring shit that people’ve complained about in much the same way since the 50s or so (e.g. Yates’ Revolutionary Road)
> But I had enjoyed working on the hard projects I'd encountered in my programing class back in high school. They were challenges I wanted to overcome. I changed my major and dove into college CS courses, which were full of hard problems -- but hard problems that I wanted to solve. I didn't mind being frustrated for an entire semester one year, working in assembly language and JCL, because I wanted to solve the puzzles.
> Maybe this is what people mean when they tell us to "find our passion", but that phrase seems pretty abstract to me. Maybe instead we should encourage people to find the hard problems they like to work on. Which problems do you want to keep working on, even when they turn out to be harder than you expected? Which kinds of frustration do you enjoy, or at least are willing to endure while you figure things out? Answers to these very practical questions might help you find a place where you can build an interesting and rewarding life.
> Eventually every programmer wakes up and before they're fully conscious they see their whole world and every relationship in it as chunks of code, and they trade stories about it as if sleepiness triggering acid trips is a normal thing that happens to people. This is a world where people eschew sex to write a programming language for orangutans. All programmers are forcing their brains to do things brains were never meant to do in a situation they can never make better, ten to fifteen hours a day, five to seven days a week, and every one of them is slowly going mad.
I know of a couple of people I really trust that tried to explain to me how they feel when they try math or programming and it's more like a physical pain almost than frustration. I always also got frustrated and always thought everyone just has to push through it but I wonder if there's something deeper. Those two people really led me to believe some of us have some harder "blockage" than others to get through, and it's not related purely to being generally smart.
I know of a couple of people I really trust that tried to explain to me how they feel when they try math or programming and it's more like a physical pain almost than frustration.
For a lot of people writing prose is like this too (https://bessstillman.substack.com/p/on-writing-or-not). Back when I taught English to college students, it felt like getting students used to creating the smallest fraction of writing possible—getting them started—was a key skill, as was trying to teach the kind of free association that leads to deeper insights. Learning to manage frustration is of vital import to many people who want or need to learn to write better.
I think you're partially right. But the "smartest" of us probably have a combination of high pain sensitivity (motivated to solve the problem) and high pain tolerance (won't give up until they do).
>a third member of our group (who had other issues) was really frustrated and took it out on us and then went to the teacher
University courses for programming generally get around this issue by having a CS110 type course that functions as a weed out class where people can find out if they have the ability to do the basic problem solving and logical thinking to succeed in that path or not. I imagine it's hard to implement something like that as part of a bootcamp though. The bootcamp really should be pre-screening people using some basic testing or such, but often they are more commercially minded and willing to accept students that will obviously fail because it keeps a steady supply of cash coming in.
Their utility is apparent if you want to just cut numbers down, but I'm not sure they automatically produce the best results if we're hoping to get all the people who could "get it".
My college weed out course experience (20+ years ago) was the first programming class I ever took. It was a C class where a dude read from the book. There was limited to no other resources outside books / internet was limited then. It did it's thing, there were fewer students by the end. I only rediscovered that I actually did like coding decades later.
The varying quality of college courses I think also kinda prove that point. It's awfully easy to say "well it's a weed out course" and just make a crappy course.
But I'm 100% with you on some way of filtering and maybe giving them most of their money back. Granted that last part ... that's going to run into the business folks call and they won't want to do that.
I suppose I was lucky 20 years ago, because the instructor for my weed out class really enjoyed the topic and included a lot of historical information and stuff, the people who dropped it or failed, did so because they thought computer science would pay well but didn't have any technical skills and weren't willing to pick up any. A lot of people just don't have the logic thinking skills for STEM type programs or have no idea what programming actually involves and these sorts of classes work because they are relatively easy for the people who succeed but still allow the people won't succeed in the field to find out early on.
Ah, yeah, I almost forgot about that. I remember students who were frustrated because of some mystery error that plagued them for hours, only for me to take a closer look and figure it out in 5 minutes. It forced me to rethink how we taught students how to read error messages, figure out line numbers and stack traces, and how to ask Google for help.
Well it doesn't help that the stack trace often doesn't follow anything but its own convention, much less the conventions of a basic English sentence. The fact you have to learn to read an error message is damning for whoever thought this would be a good error message, honestly.
It occurred to me a few years ago that the vast majority of my value as a programmer is the huge amount of trivia and giant set of heuristics I’ve picked up in years, and years, and years of work. Almost none of which came from formal education, training, anything like that.
That’s the stuff that gets me unblocked much faster than a newbie, and lets me spot shortcuts and connections and opportunities that save sometimes months of work. That stuff’s what lets me scan an exception message and stack trace fairly quickly for the one or two pieces that matter, even in some unfamiliar environment.
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.
I took a bootcamp. One day and another student and I were working on something and a third member of our group (who had other issues) was really frustrated and took it out on us and then went to the teacher.
She told the teacher "they just get it and I don't".
But in truth the other student and I were not "just getting it", we were failing frequently, we had made no more progress on what was a fairly elementary task than she did. We just kept trying ... kept our hands on the keyboard and came up with new things to try. We were no less frustrated too.
Now there's more to it than just typing like coming up with those ideas / thinking it through, but the grit to do that is not something many people have just to start.
Amusingly that seems to be a problem with seasoned programmers too. I work with some good guys who do their job well enough, but man they hit a little cognitive dissonance and they just fall apart. I'm not better and very much not smarter, I just keep thinking about the problem and keep trying. A troubleshooting mindset, curiosity, and will to keep going is hard to really test for and give to someone.