As a former instructor (not at Lambda), I'm kind of inclined to believe it has more to do with the fact that it takes a certain kind of person to put up with the demands of corporate software engineering.
Getting both kids and adults (especially kids) to figure out how to program is easy if you understand that most of the concepts are better taught visually through p5js or what have you. Once they leave that sandbox, however, and have to contend with what has to go into developing a production React app, it's a different animal.
Programming is easy. Putting a bunch of black-boxes together in order to build some app or whatever is much, much harder and more complex (and, arguably, I think that calling it programming is kind of deceptive. You're technically doing programming, but you really feel like you are? I can't say I do.)
Incidentally this is perhaps why I'm calmer than others when it comes to AI getting better and better at programming. All these researchers and companies have done is given me another black box to manage. They mean to assault my castle by first repairing its walls.
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.
> Programming is easy. Putting a bunch of black-boxes together in order to build some app or whatever is much, much harder and more complex
I would argue that putting a bunch of black boxes together is relatively easy compared all the other stuff you have to do the more senior you become.
Like resolving inter-personal / inter-team problems interfering with "coding". Or convincing your manager, a skip level manager, a skip-skip level manager and a skip-skip-skip level manager that we should do something new and they need to hand the team some money and people to get it done.
> Programming is easy. Putting a bunch of black-boxes together in order to build some app or whatever is much, much harder and more complex
This is why I think those low-level "invert a binary tree" and "find a substring in a string" questions are not really that great if you're trying to find someone to actually build an application. Many more people know how to invert a binary tree than know how to go from an empty text file to a non-trivial mobile app distributed in an App Store.
This is why I like high level design questions like: "Design an application that takes a user's GPS location, draws it on a map, and shows the 10 nearest restaurants." I'm not expecting them to open up their IDE and start coding. I want to see someone who can draw boxes and lines connecting them, and write the right words in those boxes. I want them to show which of those lines are network calls, which of them are IPC, and which of them are API calls within the actual app. Which of them are provided by the operating system and which of them will they need to write themselves? Then show what one of those lines might look like as an API. I don't care if they know the exact code that should be in those boxes. I want to know they are thinking sensibly about how everything fits together.
> Many more people know how to invert a binary tree than know how to go from an empty text file to a non-trivial mobile app distributed in an App Store.
As someone who can do both but values the latter skills much more, I wonder about what these “low level questions” actually optimize for selection at some companies.
Part of me says that many companies want to select for willingness to “play the game” / conform rather than actually code deliverable product. In fact, being able to go from blank page to decent app in an app store might be considered a contra-indicator of a good applicant — easier for them to bail and do their own thing or be a hired gun.
Most orgs I’ve seen need a relatively small percentage of their devs to be creators and builders, but a large percentage need to be good maintainers and tweakers of existing code. These are vastly different skill sets and personalities, imho.
Thoughts on this?
And what sort of company / department do you work at that needs/wants a lot kf true builders?
Interesting. How many companies need people to build things from the ground up vs maintainers/janitors of complex systems? I think the type of interview (leetcode vs system design) might depend on what category the job fits into.
Isn't the binary tree question more of a "low-pass filter"? As in, if someone can't even do that, they don't get as far as the interview where you talk about architecture and other cool things?
I've been programming professionally for 35 years. I've never needed to invert or balance a tree. When I need a tree, there is usually a library that does what I need, and if not, I can google the algorithm that I need.
I could figure it out, but the issue is that it will take time, and it is stressful. A new college grad by contrast still remembers Data Structures 101, and how to manipulate trees. This kind of "bozo filter" favors both new grads, and people who spend a lot of time memorizing trivia in order to solve these problems quickly.
Yea, the real low pass filter is simply FizzBuzz or "Write a for loop." That will eliminate over 50% of your candidate funnel who literally don't know how to program. For a real candidate, it should take 30-90 seconds and you got it out of the way.
"Invert a binary tree" like questions just filter out anyone who hasn't recently graduated with a CS degree or recently and deliberately studied algorithms. I don't think they're that useful if you want to find a leader.
I've been musing lately as well that a challenging part of the job is not just "coding", it's working with other software engineers. Each cat to herd has their own quirks, differences, stylistic choices etc. that sometimes make other cats cringe. I also think there's a big mental shift from "working harder == more output" that's very difficult for a lot of people to adapt to.
Addressing security vulnerabilities, deployment practices, monitoring, operations, architecture, gathering requirements, support questions, documentation, continuous integration and deployment, data migrations, migrating tech stacks or cloud providers for business reasons...
Very little of a software developers day is spent writing application code.
Getting both kids and adults (especially kids) to figure out how to program is easy if you understand that most of the concepts are better taught visually through p5js or what have you. Once they leave that sandbox, however, and have to contend with what has to go into developing a production React app, it's a different animal.
Programming is easy. Putting a bunch of black-boxes together in order to build some app or whatever is much, much harder and more complex (and, arguably, I think that calling it programming is kind of deceptive. You're technically doing programming, but you really feel like you are? I can't say I do.)
Incidentally this is perhaps why I'm calmer than others when it comes to AI getting better and better at programming. All these researchers and companies have done is given me another black box to manage. They mean to assault my castle by first repairing its walls.