I think what the poster meant is that the twenty-somethings will just want to hack things up on the quick in Python or Rust while the old guy says whoa, let's sit down and write a specification first, and think about how we could architect this thing, and let's make OS packages out of all the components.
Sorry, I'm not clear on what you mean: they think that the old guy will write the specification and architect everything, or they think he will hack stuff together with them?
I guess that's probably correct. The old guy will appear to be slow because he'll want to think things through before digging his fingers into the keyboard, where the young guys are just fury of a tornado, but absolutely no plan.
And planning is 50% of the work.
However, I'm not being completely fair: my experience working in Silicon Valley with 20-somethings was extremely positive. At first, they were suspicious that it was taking me an entire day what they normally do in two hours, but they did it by manually hacking. What I was doing is writing a program which, based on data, generated another program to actually perform the work. I could just tell that they thought I was full of crap, because programs which program sounds completely esoteric.
What they didn't know was that the subject of programs which program, and data driven programming, is ancient history for old guys like me: open any European computer enthusiast magazine (64'er, Dator, anyone?) from the '80's and you're almost guaranteed to find at least one treatise on the subject in almost every issue, in one form or another.
But I digress; after that one day, their jaw dropped when I would perform the same amount of work that would take them two hours to an entire day... in three minutes. Every time.
Next they wanted to know how I did it. AWK and shell. Say what?!? What is AWK?
And this is where our story really begins: I always purposely kept enough free space at my desk, and an extra chair, so that anyone from all over the company could just pick up their laptop, walk over to me and plop themselves down next to me with whatever problem they were trying to solve. I also gave them homework. Pretty soon everyone was walking around with Aho, Weinberger, and Kernighan's little Grey AWK book and used it as a reference. Then it was ANSI C 2nd edition's turn. Throughout it all, I kept teaching. There were whiteboard 1:1 classes on data structures. Then on algorithms. I loved it. And because this is regular work, I thought the exact theory that they needed to implement in order to solve the problem they were working on.
When it came time for some of the guys to switch jobs, go back to school, or go home, there were tears on both sides. I had had really devoted, bright young students, eager to learn, and I loved to teach; enthusiasm can be contagious given one is surrounded by right people. It was such a wonderful experience, and I think it was so for both sides.
I've had some pretty positive experiences working with older colleagues, so I'm totally in favor. I think the relationship can be better than either side alone because one tends to fill in the other's gaps.
Having been on both sides of the table, I can attest to it. When I was a young developer interviewing more experienced developers, I would foresee the hassle of arguing with him on everything day to day and that would instantly give negative weight to his candidacy. The irony is that I realized I had this subconscious bias only after I got older. On the other hand, when an older guy is getting interviewed by a potential peer, he should do everything in his power to appear coachable (gasp!) and flexible. The situation may be slightly different if you are being interviewed by a mid-level exec or a senior manager for a senior role in the team.
I don't know that there's anything quick about Rust. I'd probably be more inclined to use it for the second kind of project you're talking about than the first.
