4 ms·

> They haven't been staying abreast of current changes, and by that I don't mean jumping on the latest fad but rather knowing that the fads exist. Thing is if

• carlmr 3y ago
  I'm kind of happy I'm not in webdev but embedded. There's not so much fads in this area. In any case, I agree, fundamentals matter much more than superficial knowledge of fads. Also I'm glad the OOP fad of the 90s and 00s seems to be finally dead. It felt almost religious. And it was frustrating to argue against the obvious issues.
  • edanm 3y ago
    > I'm kind of happy I'm not in webdev but embedded. There's not so much fads in this area. How true is that about embedded though? I started out in that field for the first six years of my professional life, but it's been almost 15 years since then. I still know a lot more about it than the random dev who hasn't worked in it at all, but I kind of doubt I could be very intelligent about it without a bunch of catching up. (Though obviously I agree that there are almost certainly faster changes in web dev.)
    • carlmr 3y ago
      >but I kind of doubt I could be very intelligent about it without a bunch of catching up. I doubt you'd need to catch up because of expired knowledge. Rather things you forgot or areas that you didn't deal with yet. I think embedded can have a lot of depth if you get into certain details. There's basically no framework churn like in webdev, though. C and C++ are still very much current. Rust is becoming more of a contender, but still not common.
      • edanm 3y ago
        > C and C++ are still very much current. So it's interesting you say that. I worked extensively with C++ back then, and I did have occasion to do a few small C++ projects about 10 years ago, and C++ seems to have changed quite a bit. It was actually really impressive. I'm not saying it would be very hard to learn the differences, but I definitely needed a primer back then of "here's how C++ has changed", because code really did look different in some ways.
        • carlmr 3y ago
          C++11 was quite a break, C++14 very minor, C++17 a little bit more, but not as major. C++2x is doing a lot of changes, but I haven't seen much of it in the embedded world yet. Mostly because C++17 is still considered new-ish in most safety-critical realms. But say you have some C++<11 experience I think you would need a few weeks to get up to speed max.
• edanm 3y ago
  > Thing is if you’ve been around the block and have a decent understanding of fundamentals…it just doesn’t matter what the fad of the week is. It’s just noise. Old principles repackaged with different conventions. This is just not true. Entire fields exist today that didn't exist or barely existed even a few years ago. As an example, the field I've been working in for ~7 years is Data Engineering, and it was "relatively" new when I first started, or at least the modern way of doing it was. Since then, some specific technologies have become fairly commonplace, like Airflow and dbt. Does this mean everyone should have experience with this tech? No, of course not. But does this mean that someone should know that the field exists and what's different about it compared to other kinds of stacks? For some people, absolutely it's important. A "senior" backend engineer who wants to solve an "ETL-pipeline to Data Warehouse" shaped project will hopefully know that there are standard modern tools in that area, and not just to try and do it with {insert their standard backend framework}. Similarly, someone who hasn't "kept up with the times" in the world of frontends might not know much about SPAs. Are SPAs always the solution? No, there are now trends going back towards traditional server-only approaches. But there's a difference in knowing that they exist and what their place is and choosing a different approach thoughtfully, vs not knowing they are even a thing.
  • jghn 3y ago
    > know that the field exists and what's different about it This is closer to what I was trying to get at regard skills. I don't give a flip if someone knows Airflow, or DBT, or whatever. Besides, both of them are transitioning to the rear view mirror anyways. However I have found that it can be a surprisingly difficult jump for people to shift to directed graph based, data workflow thinking - some backgrounds more than others (side note: FP background tends to have no problem w/ models like pipeline oriented development) But the real issue is how many people just ossify over time. I don't necessarily care that they've been using the same Enterprise Java/XML/PHP/etc stack since the early Aughts. I care that they've turned off their brain in the process and have little to no knowledge of the world beyond it. I care that they haven't solved a hard problem in 15+ years, and instead have been making small, incremental changes all this time. I've been there myself, and it takes a lot of work to dig out of it. The thing an ideal older candidate would bring to the table is the ability to say "Oh yes, I've seen this concept 15 times over again. Here are the general pros of the approach, and here are the general cons. This new flavor patches over cons 4, 5, and 6 at the cost of losing pro 8. But we need to be careful about cons 2 & 3". The poor older candidate will state firmly that they've seen this all before and nothing new is happening here. There's a big difference between the two.
• ben_w 3y ago
  > Thing is if you’ve been around the block and have a decent understanding of fundamentals…it just doesn’t matter what the fad of the week is. You say that, but… I find I have huge problems with VIPER, and while I can't tell if it's me or the design pattern, I do notice that some developers seem to swear by it (others, including me, swear at it). I have that clip of Principal Skinner asking himself "Am I out of touch? No, it's the children who are wrong." playing inside my own mind. I don't want to wake up one day and find I'm Skinner.