5 ms·

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 th

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.

gatinsama 2y ago
Good point. What is hard is not programming, but taming complexity and scale.
duxup 2y ago
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.
- Bjorkbat 2y ago
  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.
  - kjkjadksj 2y ago
    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.
    - vundercind 2y ago
      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.
  - darkerside 2y ago
    I think you just need to rethink your feedback cadence
- spamizbad 2y ago
  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.
deleted 2y ago
[deleted]
ryandrake 2y ago
> 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.
- red_admiral 2y ago
  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?
  - kagakuninja 2y ago
    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.
    - ryandrake 2y ago
zenlikethat 2y ago
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.
jimbokun 2y ago
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.
gorbachev 2y ago
> 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.

gatinsama 2y ago

Good point. What is hard is not programming, but taming complexity and scale.

duxup 2y ago

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.

Bjorkbat 2y ago
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.
- kjkjadksj 2y ago
  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.
  - vundercind 2y ago
    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.
- darkerside 2y ago
  I think you just need to rethink your feedback cadence
spamizbad 2y ago
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.

deleted 2y ago

[deleted]

ryandrake 2y ago

> 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.

red_admiral 2y ago
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?
- kagakuninja 2y ago
  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.
  - ryandrake 2y ago

zenlikethat 2y ago

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.

jimbokun 2y ago

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.

gorbachev 2y ago

> 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.