Many (most?) companies try and paper over business or management problems with engineers willing to work long hours for little gain, and that's usually only young males/H1Bs.

Every project starts without clearly defined deliverables and a lack of leadership, but hopefully they don't stay that way.

Yes, in theory. However, particularly in the case of startups, many of which are led by smart but relatively inexperienced founders, those founders may not have the wisdom or humility to listen to the "grey hairs" who actually have seen the potential failure mode before.

A 24-yr-old CTO may have trouble leading a 55-yr-old software developer who's been coding since before the CTO was born.

Not all, of course, but far from 0%.

What I can't count is the number of times I thought I was creating something really good after the 50 hour mark. The thing is I track outcomes for quite a while, and the math starts to stack up over time, and I just opt out now.

If you're planning to work for a place more than three years, you're going to end up being the one who ends up paying for the bad ideas, whether you can connect the dots or not. You can keep almost anything working for 15-18 months, beyond that the wheels want to come off.

Source: Am management.

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.

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?

https://en.wikipedia.org/wiki/PRIMOS

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.

Hiring manager A doesn't want subordinate employee B who knows more about the work of A than A does, or is better at office politics, meeting customers, managing people, etc. Or, manager A wants only subordinates (secondary, submissive, subservient, subordinate, dedicated, devoted, obsequious, obedient, etc.!).

Manager A may be willing to hire experienced, capable people as outside consultants, e.g., lots of lawyers, physicians, licensed professional engineers, other experts get hired.

The norms of an old Henry Ford factory are still there: The manager knows more, and the subordinate is there to add routine muscle to the work of the manager.

That manager A acts this way is explained in the B-school, sociology, and public administration subject of Organizational Behavior and, in particular, well named, goal subordination. That is, manager A is looking out for the career of manager A, not to see how much smarts he can bring into the larger company.

Of course, a CEO owner might be different: He doesn't have to worry about a subordinate replacing him. But, sure, if the CEO reports to a BoD, then there is a worry that the board will kick out the CEO and promote one of the CEO's subordinates.

Ah, sure, but a CEO owner might worry about a very capable subordinate leaving and competing with him (the CEO)!

Also an older worker might be more likely to file a law suit on discrimination of some kind.

Sure, the flip side of this slippery coin can be an opportunity for an older, more capable worker -- start their own business and beat the company that is still stuck with lots of goal subordination.

Back to it!

In every job that I've had, I've known more than my manager. This isn't particularly surprising because their job is to manage rather than know the things that I know.

Cheap + naive + feeling they need to prove themselves.

It's all about costs and exploitation ;)

To be fair, if you've only had the one boss, 100% of your bosses feel the way your current boss does. There literally aren't any other examples in your work history that you can use to prove (to yourself or to others) that your boss is unreasonable or incompetent.

I also think undergraduate programs could do a better job preparing students for this sort of problem. You don't learn except through experience or maybe good mentoring that chronic crunch-time-to-meet-deadlines is a management failure, not a sign of developer incompetence.

But, yeah, I agree that bosses exploit young employees.

On the other hand, I think that I brain pretty effectively during the eight hours a day I give an employer. I don't write a lot of lines of code anymore, but I don't discard much code either. I'm good at case analysis, and if management encourages handling errors... well, I know how to do case analysis.

I like working with younger programmers. I can teach the brilliant guys to be disciplined, and that's what matters, and about all that matters. If they aren't brilliant, who cares. But if they are... they need to be taught a few things.

Still- I'm afraid I can't pretend to be young anymore ;).

It's threatening to people's narrative that if they work hard, they will be rewarded. So, obviously, an older worker must not be a diligent worker.

Cheaper is better. That's all.

Cheaper is not always better. Really what you're looking for is value, which is how much you pay for what you get. More value is always better.

If you have two people that both know nothing, scoop up the one for less pay. But if someone knows something, they might be worth the extra money because they can provide more value.

Otherwise why would anyone ever get a raise?

older people have more years experience, thus demand a higher salary.

I actually do, but I'm eager to be convinced by facts.

How would you measure this? Does anyone do that?

... which is based on the rate of response to resumes that were identical except for age, submitted to thousands of job openings.

There's also the whistleblower info that forms the basis of the RJ Reynolds lawsuit, which states they explicitly told recruiters to avoid experienced candidates in favor of people two or three years out of college.

This allegedly resulted in a unusually low number of people over 40 being hired (19 out of 1000). Similar statistics have been used recently in lawsuits against Yahoo and Google for alleged gender and age discrimination (still pending, afaik)

Of course, that's from an employee perspective :)

- Culture issues, like not wanting to go to off work events, and would rather spend time with family. I agree that these types of things should happen on work hours. This may be related to being exploited, but a lot of culture seems to reinforce the exploitation of the workers. Like work hard, be frugal, do more with less, and don't complain about sexual harassment.

- Employees being basically too smart. Both in terms of knowing when management might be leading them down a boondoggle (which seems like it would be a good thing, if the company cared, but a bad thing for an egotistical manager).

- Employees are harder to exploit. Well I think that's good for everyone. If your business model is all about exploiting your employees you've got bigger problems. I'm not going to make any mentions of car hailing services here. ;)

It does seem like a lot of the SV mentality under the hood is to exploit your employees though, as much as possible, and pay them as little as you can. It's only the competition that will take them somewhere else to be exploited for slightly more money.

Looking at this from a business case, having a smart person notify you when you're getting into the swamp sounds like a positive thing. Especially if they've been in the muck before. Throwing away weeks/months of work is pretty common, and a huge source of wasted resources.

So imo the underlying issue is that software work, unless it rakes in bags of cash, is not respected as a professional field. (Ever see anyone push to "teach kids how to argue a case in court!"? Coding is information age labor. Needs "young muscle" paraphrasing our absent host, Paul G.)

Possibly something has gone wrong if you are chasing programming work after 40 -- channeling society here, relax -- and yet as an older gentleman coder :) I take quiet satisfaction at the self destructive behavior of the young filters poo pooing "experience". 40 rolls over before you know it. Ding.

Also, in my experience, younger employees are more prone to leaving after a couple of years, because they want to see what else is out there. Whereas older employees tend to stay longer (have already seen many different places).

That being said, people with kids do typically have stricter schedules (like picking up kids from daycare) than people without kids.

Interesting point on the staying longer. The amount of time you sink into training a person on your system / codebase / company etc you're not getting back. People generally only start to become productive after a couple of months anyway.

(Edited: you said it was a pro)

It's really frustrating that parents bring their sick kids to school, and even sick teachers show up to teach because they can't afford to take the time off (apparently). This winter was brutal, I've pretty much spent all of my vacation time just taking care of my family.

Obviously this is just an anecdote but I suspect that many parents are either taking a lot of time off, or just dropping their sick kids off at school.

I had a go at her, because I'm asthmatic. Someone brought a cold into my previous job, and I spent six months with the symptoms of it (really). Another time, someone brought a cold in that hit my asthma so bad that I needed a break after rolling over in bed. My doctor nearly hospitalized me over that - apparently my airways were really narrow.

The other woman from the marketing team jumped in, explaining that she doesn't usually get the cold, but takes the disease home on her hands and clothes, her young kids pick it up, and then she ends up spending a month off looking after them, using all her vacation time just like you did. After all her kids have been sick with it, she'll get it, and she doesn't have any vacation or sick days left.

In the end, it turned out that the hero who never let a "minor illness" get in the way hadn't thought about anybody else catching it.

When there are big age differences, there are natural tendencies towards aggressive prove-yourself competition or slightly compliant deference. These are probably built into the primate minds that we all have.

True peer relationships of any kind are much rarer across decades than between people of similar ages. And there are good reasons for that - not least the way that different decades tend to have different life challenges.

So I think discussions about the merits - or not - of older people are beside the point. If most people in an office are in their 20s, hiring someone in their 50s as a peer is going to be pretty awkward for everyone.

Of course this isn't how it should be. But - no matter what the law says - it's not very realistic to pretend it isn't an issue.

The solution, if there is one, is to deliberately create a polyculture of diversity of all kinds. Hire people of all ages, cultures, genders, and backgrounds. Dammit. Then everyone gets to be different, and the culture has the potential to be a lot less linear.

But SV isn't so interested in that. Until mostly white/asian bright shiny people in their 20s stop beaming enthusiastically out of "About us" pages - extra points for a group shot - SV will continue to be a monoculture, and a lot of practical talent and experience from outside the bubble will continue to be wasted.

At almost 50 the desire to spend 8 hours a day with 20-30 year olds, encouraging enthusiasms, persevering in mentoring and then learning/acceptance of new ideas/tools, being persuasive about experiences in project scope/direction and contributing as part of a growing creative team effort is exhausting.

Not to mention the older you get in this industry you see a lot of reinvention/progress the 'wrong way' (or blatant ripoffs done for profit) which you just become opinionated about.

You don't create a hip, cool, sexy work environment filled with hot, good-looking people who all want to bang each other by hiring some old geezers with grey beards.

Everyone should be under 30 and look like an actor from a Crest Whitestrips commercial.