65 replies
1d1h
The model is broken. Too many people want to learn to code, not everyone can do it well.
The only way would be to filter many candidates going in, but the negative press would be huge. So you end up with huge cohorts of people who can't code, and you have to make the money back somehow. Good teachers need to know how to code well, and those are expensive too. And, let's face it, the internet is full of great material to learn to code for free. If you are not motivated enough to learn by your own, all the time, I don't see how a bootcamp will give you anything.
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.
The frustration factor is a big deal.
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.
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.
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"
You're not alone. Hard conversations are a difficult skill, and not one most people learn or even think about as a skill. Check out radical candor. https://www.radicalcandor.com/blog/what-is-radical-candor/
It gets a bad rap, but for me, it was a really useful way to think about giving people the messages they need to hear.
Good luck! It's not easy, but it's key to leveling up as a professional, and I would argue, as a human being.
Let's face it, most of the time the tools are the problem. That is why, whenever possible, I write my own tools.
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.
Well, try running numpy on apple metal.
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.
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.
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.
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)
“I HAVE NO TOOLS BECAUSE I'VE. DESTROYED MY TOOLS WITH MY TOOLS.”
https://www.usenix.org/system/files/1311_05-08_mickens.pdf
I keep pulling up one of my favorite bits on this attitude http://www.cs.uni.edu/%7Ewallingf/blog/archives/monthly/2018... - https://news.ycombinator.com/item?id=26209541
... And there's also Programming Sucks ( https://www.stilldrinking.org/programming-sucks ) which takes a rather hyperbolic style of writing on the subject.
The penultimate part of it is:
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 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.
Sounds like cooking for me. By the time the meal is ready, the stress of making it has eliminated my appetite.
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).
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 think you just need to rethink your feedback cadence
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.
I've got mixed feelings about "weed out" classes.
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.
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.
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.
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.
In my experience, a good growth company will have at least the three following stages that can yield a healthy ROI with good builders:
1. Initial product (start up stage).
2. Secondary products and upsells.
3. Internal tools, iterative, and often in perpetuity for the life of the company.
I am not sure the “builders” should ever be more than about 5-10% of the programmers except in early stage 1.
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.
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.
Good point. What is hard is not programming, but taming complexity and scale.
I think there’s probably room for something like: programming with less CS. But I mean, we already have trade schools and community colleges for that sort of thing.
I also think there’s a ton of value in everybody learning a little bit of programming to help them automate things like office jobs. But that’s have to be carefully handled with nice intuitive libraries and thoughtfully restricted network stuff.
Getting teachers for this sort of stuff is hard, but maybe the tech bubble will pop soon.
I'm curious how much Calculus as a prerequisite is a barrier to entry for students. CS as a topic is not hard, but a lot of students are blocked from entry with fairly rigorous Calculus requirements.
I'm sorry, but if you are unable to understand the basics of calculus and discrete math, then you should not be in a Computer Science program (with emphasis on the "science" part). CS isn't just programming - it's the theory of how computers work and math is an integral part of that. Just because you don't use it every day in the job itself doesn't mean that the information is useless.
I think the issue is that many programs expect students to understand 'the basics' of calculus as an academic mathematician understands them, which I would consider to be more suitable as an upper level elective for a CS program.
A fun exercise would be to have graduating CS students take the same calculus exams that were required for admission to the program. I would expect that 10% would score much higher and the other 90% would score much lower.
I worked with students in a “intro calculus for humanities” type class for many years (as a sort of undergrad tutoring role, so, it was a while ago, I’m old now). Despite this experience it is pretty shocking to me that there are, like, actually adult people walking around who can’t at least do a derivative.
Spending too long in STEM academics absolutely warps your view of the mathematical skill floor I think.
At one point, I was able to do 3-dimensional vector calculus on electromagnetic fields. Now, I'm not sure I could do even a basic derivative.
Use it or lose it.
I mean, even when I was tutoring it I’d double check most of the equations just to be sure.
I’m sure chain rule, product rule, and polynomials would come right back to you, and everyone has to look up the trig functions anyway.
While I've certainly found calculus useful on many occasions, I don't think calculus is a particularly important requirement for understanding how computers work.
On the other hand, calculus prerequisites are a filter that filters out anyone who might be inclined to say "math is hard" and give up, which might correlate with people who say "computers are hard" and give up. Or in other words, it's easier to say "Prerequisite: Calculus 2" than it is to say "Prerequisite: be sufficiently determined to complete something many people find hard and give up on, or be one of the people who found it easy to begin with". And lo and behold, rather than getting people taking an advanced CS class and giving up, you instead get people not taking the class in the first place because they don't meet the prerequisites, which makes numbers look a lot better.
This is not the best solution for the problem. It's the solution most CS programs take, though.
(Necessary disclaimer because internet discourse: this is a comment on CS education in general, not a comment on Lambda School in any aspect.)
Its really only important because you need it to truly understand probability and statistics, which you need to really understand how computers work.
I dont get why so many people want to drop calculus from computer science curriculum. Calculus is necessary for basic science and math literacy. People act like it's graduate level math and not something easily learned by any somewhat studious high schooler. 4 year CS programs are supposed to give you an education which is a foundation for wherever your career takes you not teach you to be a create-react-app code monkey for life. What if you come across the need or desire to do anything related to science or engineering?
I'm 60, and have never used any calculus on the job. I did need to relearn some linear algebra when doing game programming, but these days most of the heavy lifting is done in the game engine for us.
Nothing I've done on the job involves deep computer science. There are people who need to know that stuff, but they are specialists. Building CRUD servers or web frontends uses very little of what I studied in college, beyond basic understanding of data structures and algorithmic complexity.
I'm glad I learned CS, and wish I had learned more of it, but it should not be a requirement for getting a code-monkey job.
People want the easy money that a programming job represents and resent anything that gets in the way of getting it.
I think it's worse than not doing it well. It's more like struggling at the basics. The incentives of these camps favor quantity over quality.
Programming is really not as hard as you're making it out to be. I've taught it to beginners both children and adults and they struggle but they all learn it. Professional software development is quite difficult, but programming is only a portion of why. And even then, software dev is only like the second or third most technically difficult job I've had. Any welder or marine upholsterer or nurse or whatever has about as intellectually demanding a job as we do.
I'm sorry, but this take is just ridiculous. I say this as somebody who has worked in various fields (education, medicine), gotten my private pilot's license, worked in education as a foreign language teacher, and done EMT and paramedic work.
Your examples are just absurd.
Software development and software engineering is such a vast and broad field that your comparison doesn't really apply. It's more of an indictment of your particular position than anything.
If all you were doing was tweaking Tailwind styles, and installing and managing WordPress, then I suppose your assessment is somewhat applicable.
But for those of us who have worked as proper software engineers (I don't particularly care if this sounds pretentious), I've never encountered more intellectually challenging problems than developing brand-new solutions and algorithms to solve complex issues.
If you had said "doctor" or even "nurse practitioner," then maybe. But the idea that working as a nurse (for 99% of nursing work) is as intellectually challenging as software engineering is just patently absurd. I don't even know what marine upholsterer is so I can't comment on that one.
The same goes for welding, even if we went so far as as to say UNDERWATER welding. This is a position that nobody in their right mind would claim is intellectually challenging. That being said it is highly paid for two reasons: it's a very high-skill job requiring substantial training (in much the same way as getting your ATP), and it comes with a set of significant risks.
Let me give you ONE example. Just one.
I remember my first job out of university as a C++/C# developer. We had a large technically minded QA team. A lot of our feature work was in SDK plugins developed as DLLs which we would license to external companies.
We were running into an issue where it was difficult for the QA team to quickly iterate/field test our work without us having to write custom test harnesses for them.
I remember reading through the SDK reference manual for C# and reading about this concept of Reflection which would allow one to dynamically discover information about classes, methods, properties, fields, events even to the point of examining the actual arguments that could be passed in and their allowable data types.
All of a sudden I realized that I could write an entire dynamic testing harness (which I dubbed "Pandora's Box") that could dynamically generate UI to run tests by pointing it at any of our managed DLLs with support for feeding in CSV to manage regression tests as well.
I did this - I came to the realization, I figured out how to implement it, everything was me. I soon left the company after a couple years, and learned later that it became an important internal tool used for many subsequent years beyond my tenure.
That is one just ONE example of a thousand things that I've personally come up with and developed in my stint as a software engineer. And that was 6 months out of university as a mere associate software engineer.
I also came up with a novel way of doing OCR 15 years ago by combining genetic algorithm spinning up tesseracts with markov probability modeling against a common English corpus which exponentially improved our company's SOTA text recognition. And ON and ON and ON.
Yeah now that you put it that way it may have something to do with our individual particulars but I just don't find it as difficult as you seem to sorry.
Are you doing it one on one or in a classroom setting? In former, I imagine the success rates would be higher.
It was a code school. Not lambda but a comparable curriculum & setting.
Allred?
Lendup.
https://en.wikipedia.org/wiki/Bloom_Institute_of_Technology
That might be true if the company was honest. But this was clearly fraud. So go ahead and blame the victim.
In fact, I am blaming the company from the very start, since they are the ones who promised something they could never deliver.
People don't want to code. People want to make a living, and the people who exported their jobs overseas and gig-ized what was left told them to "learn to code."
Why don't you just fire them like any other job where people can't perform the work? This isn't a unique issue with programming but the hiring managers that exist in programming act like it is and have come up with crap like leetcode and passive aggressive games like soft firing people by paying them salary and not giving them work. Imagine a landscaper thats been soft fired, it would be unthinkable.
I don't think filtering candidates would cause negative press. In fact the comparison to traditional colleges is stark: colleges like to brag about how "selective" their admission process is. A coding boot camp doesn't need to be that rigorous, but at least they can demand things like a bachelors degree in any field, a few years of work experience in any field, etc. So the target audience becomes more like already reasonably successful workers who want to switch fields.
last week two students started learning on freecodecamp using a laptop i provide for them in my home. they work on their own, but they can ask me when they get stuck. so far it was mostly telling them to closely reread the instructions to see if that provides a clue. when they finish the html course, i'll pay them to update my website (it's all static html) then i'll see if i can get them started on javascript.
not sure yet where this will go. the first student that tried that gave up after a few days. don't know why. maybe he felt it wasn't for him. fine.