The solution to the happy-hour problem is to have your happy hours during work, not after hours. Even I, who am young, healthy, no kids and loves beer, would get tired of having to go to xyz happy hour at 6p.m just to keep my edge.
The other thing: I bet that old guy is the first one in every morning. And probably brings his lunch every day. Also is not interested in an afternoon ping pong break. Translation: He or she probably actually works more, despite being "at work" less.
I once watched a fistfight almost break out in the office over threads vs. event loops. Both engineers were in their mid 20's (as I was, at the time).
From my limited experience, pig headedness seems to be a personality trait - not something intrinsically age related.
I get that it might be amusing for you when people complain about an overtime that's three hours less than your total workday, but it really is quite unnatural for someone to work for that long. Spending 70% of your waking hours at work is not something to be proud of.
The rest is quite good to hear as an anecdote, however. It's great to hear about teams that socialize in a way that doesn't involve beer, pingpong, or partying. Strange sort of frat culture that we live in.
Why are you working 11-hour days when your colleagues are working 8-hour days?
Sometime people go out to a bar or something afterwards. I may feel like I'm missing out but it never feels like something I "should" be doing.
It's entirely possible to do your research and evaluate a framework, language, or tool without having to use it, just like I don't have to go out and shoot some smack to know that heroin is probably not for me. Being able to evaluate what your needs and wants for a tool are, without having to write a To Do list is a useful skill.
Research may be enough. But research + trying a simple prototype is always better.
There is a lot in, say, PL/I that should be in more recent languages but is not. Gee, guys, C was always supposed to be a toy language, to run on an 8KB DEC PDP-8 (IIRC), and C++ was originally just a Bell Labs pre-processor to C. In contrast, PL/I was a very carefully designed language. IIRC the Multics and Primos operating systems were written basically in PL/I.
Yes, D. Knuth's The Art of Computer Programming is old, but heap sort, the Gleason bound, and AVL trees are all in there and still relevant. Also that is one of the best places to learn the combinatorial and probabilistic math for finding big-O evaluations.
But, statistics in Python and R? Some people got started in such things by writing their own code, using the IBM Scientific Subroutine Library, using SPSS and SAS. So, who is better at digging into statistics via Python and R? Also some of the older guys actually took good courses in mathematical statistics and know about minimum variance, unbiased, maximum likelihood, statistical hypothesis tests and the Neyman-Pearson result, etc.
I thought Primos was supposed to be some Fortran dialect (FORTRAN IV in Wikipedia). Then a PL/I variant much later. I've been citing it as an OS written in a Fortran-like language given I had no data countering that. You got some?
I managed a Prime system when I was in grad school and later lead an effort to get a later Prime system when I was a B-school prof.
Prime was a cheap Multics complete with processor security rings, gate segments for user programs to call into the OS, an hierarchical file system, and capabilities and attribute control list hierarchies based on the hierarchical file system. The file system used the relatively large physical record size of 4096 bytes, and the file system continued to work great as we ran hard disks for years without ever once doing anything like a decompression to get all the physical records of a file closer together on the disk for better performance.
For more performance, they had closely coupled systems.
The terminal I/O was super nice and easy to use, 8 bit ASCII at 9600 bits per second, easy DIY cabling, with easy to use DC1/DC3 XON/XOFF handshaking protocol that worked well with lots of ASCII devices, e.g., a nice HP color plotter and the Xerox Diablo daisy wheel printers. Users were not locked into too expensive terminals but could do well with just dumb glass teletypes.
Their standard text editor had some nice ability to be programmed, and they had a nice interpretive scripting language. They had a plenty good enough word processing program well in the theme of the Bell Labs RUNOFF. Prime used that and daisy wheel printers to prepare their documentation.
It has been claimed that the Intel 286 architecture borrowed heavily from Prime's architecture.
On the first Prime I managed, I did a lot of applied math for US national security and also did the software and typing for my dissertation. One prof needed a little clarification in one paragraph, so on the weekend I typed again for a few minutes, had the daisy wheel printer retype the whole dissertation, and submitted the new version on Monday. That is the version that was accepted.
Our work for the Navy very much needed better word whacking: Once we submitted a report from typewriters with so much correction fluid the Navy refused the report. As soon as people saw the file system, terminals, text editor, RUNOFF, and the daisy wheel printer, each of the secretaries begged for and got their own terminal, quickly got a little instruction, taught themselves, kicked their typewriters out the door, and became terrific with word processing. Suddenly the volume and quality of the word processing went through the roof.
We paid for the Prime with about 18 months of our earlier time sharing bills and got MUCH more computing than we ever had on time sharing.
The Prime I helped the B-school with did student work, faculty work, administrative work, alumni office work for fund raising from alumni, and word processing.
The alumni office did a little work with data base and sent boxes of personalized letters to alumni for fund raising. The little system the student assistants put together was copied by the central university computing group for use for the whole campus. Just from the alumni work, the system likely paid for itself in green dollars many times over.
We had a quite nice collection of scientific and engineering software, actually nicer than the IBM Watson lab at Yorktown Heights had when I later went there for work in an AI group.
The system was wildly successful for years.
To me, at the time, Primos was nicely better than Unix. Prime had a great opportunity to port Primos to the Intel 286/386 but didn't and missed out.
IIRC, the first computing Bloomberg used for his trader information terminals was from Prime.
Prime had a good thing going, but Wintel beat them but should not have been able to. Primos was far ahead of Windows for a long time and could have been ported to Intel long before, say, Windows NT or 2000. And I can believe that Primos was relatively secure.
IIRC, Primos ran in about 40 KB so would fit into even the 640 KB of the first PCs and certainly would fit in the memories of the 286 and 386 systems that ran Windows 95, NT, 2000, etc.
When I was in grad school, I was reading the material from D. Knuth about his TeX mathematical typesetting system and hoped to get that on the Prime at the B-school. Well, one of our bright computer center guys got started on porting TeX to Prime. We met Knuth at a conference, and thanks to that guy our Prime became the official distribution point for TeX on Prime. The same guy also got us going on e-mail.
The B-school Prime was a good site and very successful for 10+ years.
After you've seen the same mistakes repeated with a cycle of about 15 years, that happens.
Remove the word "decade" and that could describe people from just about any demographic in tech - millennials, Gen X, etc.
>"and complain about the cyclical nature of programming"
How is complaining about that particular thing different or worse than complaining about why language X sucks because it doesn't have generics or feaure ____" or any of the other complaints about various languages or frameworks that come up on HN all the time?
>"They also seem to usually not go out to happy hours/events with the team to get to know one another as often, so they're excluded a little more, which leads to fewer people getting to know them."
The only way to get to know people is to go drinking after work? You know you can go out for coffee and lunch with people too right? Or is that somehow less meaningful because it doesn't involve booze or craft beers?
Honestly your comments come off as ageist.
The most practical reason to look for younger workers is to find people willing to work below their market rate because they are bad at negotiation. A decade of 5-10% raises can usually keep them happy which is a huge net win as they end up even further behind what the market would pay them. The problem is they only ever learn your internal system and often become blind to it's issues.
This, right here, is why Silicon Valley has problems with diversity. As a rule of thumb, the only people who actually want to go to happy hour with their co-workers after 8+ hours of taxing mental work are 1) young 2) white and 3) extroverted. In other words, they fit the "brogrammer" stereotype. I've never really liked going out with my co-workers after work. When I'm done, I want to go home and decompress, not deal with another two or three hours of enforced social interaction.
Your well-intentioned comment has the pattern:
"I've worked with some extremely smart <class of people>, who <positive comment>. My impression is that usually, in my experience, <display a different pattern of thinking to what I expect>. They also seem to usually not go out to happy hours/events with the team to get to know one another as often, so they're excluded a little more, which leads to fewer people getting to know them.
It's just that most of the <class of people> I have personally met seem to have the traits I described above. This would give me a little pause when choosing between equal candidates for, say, an angular dev position where both candidates have equal experience in the stack, but the <class of people> one has the baggage(?) of <difference>. I would likely have an unconscious bias to hire the <more similar to the norm> one."
Now, replace <class of people> with "women" or "muslims" and think about how it feels for people to be cast in a generalization. If it's not right in those cases, it's not right for experienced developers either.
What is wrong with this? There are cycles in our industry. Sure, it's not exactly the same each time around but the themes go back and forth.
At the risk of speaking for someone else, my impression is that "cyclical nature" is fighting the last battle filtered through cognitive dissonance. It also comes across as aloof and/or academic to some people.
This should vary with context and one must be humble enough to accept the grey hair's argument backed by facts if it is valid and move on. Win win for everyone.
>> They also seem to usually not go out to happy hours/events with the team to get to know one another as often, so they're excluded a little more, which leads to fewer people getting to know them.
I dont' understand this craze to know them? Why, for what?
If after working/collaborating for 8 hours with some one over days/weeks/months, you cannot figure out their personality and working style and as long as it is not a disruptive one, there is no point in knowing. This knowing is just substitute for loose pointless talk.
>> I would likely have an unconscious bias to hire the younger one.
We as a software industry must seriously look at how successful sports teams are run and stop this BS about we a family etc whose frailty shows up come layoff time! Every successful sport team is always a MIX of YOUTH and EXPERIENCE.
I have seen exceptions, one of the PMs on my current team must be in her 60s and she exhibits none of the characteristics above and is a really amazing, smart person. It's just that most of the older people I have personally met seem to have the traits I described above. This would give me a little pause when choosing between equal candidates for, say, an angular dev position where both candidates have equal experience in the stack, but the older one has the baggage(?) of having been a programmer since the 70s and knows COBOL or something. I would likely have an unconscious bias to hire the younger one.