4 ms·

I’ve been programming for 10 years, and as you’d expect know a lot of people with a few more or less years programming. I think all the “kids these days” gripe

I’ve been programming for 10 years, and as you’d expect know a lot of people with a few more or less years programming. I think all the “kids these days” gripes only apply to people’s first few years. You can argue they’re formative, but most professional programmers will quickly need to evolve beyond “take message literally, ask online for help, paste error message into google/SO” to be good at their jobs. I don’t know anybody beyond entry level who operates like that. I rarely take things literally like you said (though I may start by giving it the benefit of the doubt), I always just check the actual code from the thing emitting the error message, read the source of libraries I’m using, seek out documentation. It just so happens I can do all of that from my computer rather than doing some of it with a book.

capableweb 4y ago
I've had the unfortunate luck of working with a couple of people with "senior" in their title that once faced with an error message from a open source library, starts their troubleshooting with searching for the error message and if nothing comes up, opens a issue on the issue tracker and then wait. They didn't even consider digging into the source code of the library to figure things out themselves. I haven't worked with a lot of people like that, but enough to guess that there is quite a bit of people who work that way.
- orwin 4y ago
  To me, it is only an issue if they sit still after and do not start to work on something else. But I am unashamed to admit that if I don't find the error in github/gitlab issue tracker, and if it seems to take more than 20 minute to investigate, I'll open an issue then move on (if I already know the library, if it's new to me, I'll assume Pebkac for at least two hour and try to rubber duck the issue)
  - Mezzie 4y ago
    Depending on how much you have on your plate, this is ideal from a time management perspective. Knowing when and how to delegate is a very important skill. Just because you can do something doesn't mean that it's a good use of your time.
orwin 4y ago
Hey! I still do that! But it's true that after a point, the only errors left are the ones that can only be resolved by reading the documentation and experience (only 4 DELETE per hour, and you throw me an undocumented 503 error? Really?), and llm can't really do it for you.

capableweb 4y ago

I've had the unfortunate luck of working with a couple of people with "senior" in their title that once faced with an error message from a open source library, starts their troubleshooting with searching for the error message and if nothing comes up, opens a issue on the issue tracker and then wait. They didn't even consider digging into the source code of the library to figure things out themselves. I haven't worked with a lot of people like that, but enough to guess that there is quite a bit of people who work that way.

orwin 4y ago
To me, it is only an issue if they sit still after and do not start to work on something else. But I am unashamed to admit that if I don't find the error in github/gitlab issue tracker, and if it seems to take more than 20 minute to investigate, I'll open an issue then move on (if I already know the library, if it's new to me, I'll assume Pebkac for at least two hour and try to rubber duck the issue)
- Mezzie 4y ago
  Depending on how much you have on your plate, this is ideal from a time management perspective. Knowing when and how to delegate is a very important skill. Just because you can do something doesn't mean that it's a good use of your time.

orwin 4y ago

Hey! I still do that! But it's true that after a point, the only errors left are the ones that can only be resolved by reading the documentation and experience (only 4 DELETE per hour, and you throw me an undocumented 503 error? Really?), and llm can't really do it for you.