Outside of extremely rare triage situations, this limit is true for all developers, regardless of age or quality of output. Beyond about the 6 hour mark, people can force themselves to sit in a chair and hit keys on a keyboard like the Swedish chef from the muppets, but it's pure management denial to believe those hours count as "productivity" and in fact when the defect rates start to get high and fatigue compounds and morale drops, it's really anti-productive.
Really, younger age is just usually correlated with fewer extracurricular responsibilities, i.e. home repair, health maintenance, domestic responsibilities, marriage, children, etc. These things tend to increase with age, making it a scheduling impossibility for older workers to sit in the chair at 8 pm going "hur duh dur" while slapping keys.
Since I log my own hours I became full aware of this 6 hours "ceiling" in the long term, for a few days I could work for many more hours, but that would have a big price to pay in future productivity. In the beginning I felt bad, as if I was not able to produce as much as other people leading to a lot of anxiety. As I realized that my actual productivity was going up, compared to my older self and other peers, I embraced it.
Now I work 6 productive hours and to me that's 8 hours of work, my results are better month by month, my quality of life is better and my anxiety is more controlled. Everybody wins.
"Fluff" time is for sitting in meetings or writing reports, as work functions, or for just looking busy. I intentionally avoid doing real work that requires any focus or creativity in the fluff slot. After six hours of real work, any more time spent doing the same thing starts to become counterproductive. So just leave it for tomorrow.
I have been more productive while explicitly dedicating 2 hours a day to getting nothing useful done, than when trying to stay focused on one thing for 8 hours, and ending up goofing off, getting sidetracked, or procrastinating for some amount of time anyway.
That's the theory, anyway. My current employer doesn't keep my pipelines reliably filled. During the dry spells, I have a hard time expanding the fluff slot to more than two hours, and end up doing stuff like coding stupid CLI games, or vectorizing the company logo, or setting up a new vanilla VM that I might not ever use.
I can still code for longer than this, from time to time, but only if I already know exactly where I'm going. Even then it's playing with fire.
Maybe sober, but that's not the limit once you factor in the rampant use of amphetamine.
It’s true you can knock out a 10-20hr session in essentially one sitting, but it’s not a good habit to set for yourself or the industry
edit: https://www.theguardian.com/books/2008/dec/02/jack-kerouac-r... the "scroll"
Going "out of [your] way" to hire older devs sounds like age discrimination. AFAIK, age discrimination in this direction isn't illegal in America, but it seems odd that you would respond to an article decrying age-discrimination by proudly declaring that you discriminate too, in the opposite direction. Maybe you just meant that you almost always find the qualities/compensation-demands you're looking for in older applicants rather than younger ones, but your phrasing doesn't seem to indicate that.
In fact, you should do this to be inclusive. There are a lot of unconscious things hiring managers do that remove themselves from the running of highly qualified candidates.
Want to remove yourself from consideration from young talented female developers? Create a laundry list of "requirements" even though you consider them "nice to haves." Also add plenty of trigger words to make your business seem unattractive.
https://hbr.org/2014/08/why-women-dont-apply-for-jobs-unless... https://www.forbes.com/sites/hbsworkingknowledge/2016/12/14/...
Avoiding hurting yourself in the eyes of candidates you'd like to include is far from being discriminatory to other groups.
Wait...isn't this exactly what the article is talking about?
Before online advertising you kind of had an idea of what the target audience of TV channels, news, and radio was like, but it was very fuzzy and you certainly weren't excluding people not in your target demographic that happened to utilize those media platforms. Women reading male fitness magazines or men reading female lifestyle magazines weren't the primary target of ads in those platforms, but they could certainly utilize what was being advertised if they so desired. The same is not true of online advertising today.
Facebook is more in the position of a newsstand than anything else, and it would be blatant discrimination if a newsstand wasn't allowing older people to buy technology magazines, for example.
Everything is discrimination - if you're seeking to hire a software engineer you're probably going to discriminate against people who don't know how to code, people with low IQs, people who can't get along with the team, etc.
The question becomes, is the discrimination legal and/or ethical and based on actual business needs? If the GP noticed they can get a seasoned developer for only slightly above the price of a jr developer (who sees themselves as "senior") , that doesn't really seem like immoral discrimination to me, especially if they are more than willing to also hire jr engineers at jr engineer prices. Most places cant, for business reasons, survive alone solely on senior engineers.
(Interestingly enough, in the US, discrimination based on age because "old people are stupid" is illegal whereas discrimination on age based on "young people are stupid" is not.)
Somehow the word has been twisted to be almost exclusively negative.
But show me an organization that doesn't discriminate, and I'll show you an organization of utter incompetence.
"President" was chosen as the title of the head of the US Executive Branch because it was a title with nearly no prestige; it was the sort of name you'd give to the Robert's Rules enforcer for community meetings. Words take on a connotation history provides them.
"Differentiation" is the word I have to use now.
Webster gives pride of place to both the transitive and intransitive definitions that could fit your "once upon a time" definition.[1]
Furthermore, of the six definitions given, five are what I'd consider a trait or ability that is wholly positive to possess. Only the 2nd definition for the intransitive form has a negative connotation.
> But show me an organization that doesn't discriminate, and I'll show you an organization of utter incompetence.
Any organization that isn't utterly incompetent would avoid using the ambiguous word "discriminate" in place of the unambiguous phrase "use good judgment."
Also, HR is just one tiny and narrow domain of human affairs. Music, writing, even dating see way more use of the positive definitions of "discriminate."
In practice, discrimination has largely negative connotations https://english.stackexchange.com/questions/183093/is-there-...
> "use good judgment."
"The screening exercise _____ aggressively."
* "The screening exercise uses good judgement aggressively." Awkward.
* "The screening exercise filters aggressively." No implication that choice is based on the candidate's characteristics instead of random chance.
* "The screening exercise distinguishes aggressively". Sounds odd, plus has positive rather than neutral connotations.
* "The screening exercise differentiates aggressively " Best one, though it doesn't hint at the pass/fail nature of the distinction.
I do wonder why people wouldn’t hire older programmers or engineers though. A lot of them are still extremely nerdy about their hobby, they have profound amounts of experience and they’ll typically both be able to follow orders and voice their opinions. Often they’ll have a good grip on work life balancing as well, making them less prone to stress.
I’m not sure ageism is really a big problem though. I haven’t seen any unemployment numbers on old programmers being huge, though I will admit that fear of abuse was one of the reasons I went into management.
That being said, I do think people should plan their staff to be without huge age gaps. It’s one of the few things that has an empirical proven negative effect on teams. But that goes both ways.
>I’m not sure ageism is really a big problem though.
I'm not sure you can put both those statements together without sounding uninformed.
The same reason the military prefers younger over older. Younger developers are easier to manipulate, overwork, and underpay. They are easier to mould and shape in conformance with corporate "culture fit", and they're less likely to question authority. They also don't have the wisdom yet to know when they are being asked to drink the startup Kool-Aid.
Of course, that doesn’t have much to do with age - one can be closed to new ideas at any age.
* fixing the problems they had at their last company, inappropriately so to the point of over-engineering. Sometimes it’s not elegant, but hardened against the wrong things
* insistence on older technologies and patternss that they’re familiar with even if not concise
Not necessarily if it has to be built in some stack or language flavor of the month (and VC's check). If you change entire tool-sets every 18 months, I bet the younger folks will be able to re-learn faster. I'm 40+ myself, and am saying this from experience. It's unfortunate our industry is so fad-driven, but I didn't create humans, I just work among them.
I recommend one focus on a domain (insurance IT, healthcare IT, etc.) when they get around 40. Your domain knowledge will have market value. Reformatting your head all the time is not a good career strategy for most. (There is some value to some new IT things, but a good portion is hype and gimmicks.)
And i'm also not sure if it's true that 'we' would be slower to learn these things; I keep on top because, I feel, that as CTO, I need to understand what is out there and if there is something promising that can help us long term, I want to be early to find it. So I do learn every new fad, and, not to sound cocky because I believe it's just experience, there is not much to learn; they are all, in a lot of ways, rehashes. Sometimes you see something really innovative, but that's not the thing that ends up being a fad or even remotely popular. After 30+ years of programming in many different technologies/projects (especially the functional experience helps a lot these days) etc it is easy to recognize the patterns and the goals the programmer was going for when building that new tech. Not that I would want that job as a non-cto at a startup :)
I feel like in the case of the later, the priorities are much more in the order of 1) manage business risk wrt technology, and 2) manage organizational processes wrt technology.
Tech is only the thing that gets you to the thing and the usefulness of anything new is either a) readily apparent (like from orbit), or b) can only be brought in from outside talent (failure of priority #2) or learned from falling on your ass (failure of priority #1).
My point being, it is of little benefit in this scenario to spend any time actually learning the latest fad tech.
This is another place where experience helps. I can definitely learn a new framework faster now that I've had 10+ years experience than I could when I first started.
You might be able to find more younger people who already know the framework of the month.
So that others benefit from my experience: the cheat code to this is to work in marketing tech. You will have domain experience in all of these in a relatively short time because you will have had to deal with partners & clients from these domains.
You also learn very quickly how any company makes its money, what they consider positive contributions to the bottom line and how you can be one of those.
Except for at the fringes of new tech, traditional business is far more personally rewarding than working in the seeking-funding startup snakepit.
Also, maturity often comes with a reduction of the ego-driven drama friction which can make people so much more pleasant to work with.
Strongly preferring less experienced devs because they can work longer (which they need to, partially to compensate for their lack of experience), is both tragic and comical. It’s likely the pay is lower for the younger devs but the very practice of working long hours has been proven as detrimental to quality.
I'm not sure that's the whole story, though, especially considering how much of the "industry" is VC-driven and how few VCs are engineers.
My understanding is that silicon valley hasn't cured aging yet, so until that happens, this seems like yet another market distortion that favors employers at the expense of labor (or 'YAMDTFEAEL' for short)
Are you treating everyone in your organization as equivalent resources or are you allocating people based on strengths/specialties?
Having a heterogeneous team with breadth of experience across the stack helps to isolate you from the real business risks of group-think and "not knowing what you don't know". It's a hedge and a pillar of a resilient, long-term-oriented organization.
If you just want to have a get-shit-done culture, move fast and pivot/abort when things get bad, you probably want all 20 year olds. However, if you look at the organizational structure of banks, who are literally in the business of managing business risk, you will see diversity and redundancy in hiring.
Side note: Every single time I've seen a complaint about X group doesn't work as effectively as Y group, it's almost always a management misallocation of (human) resource. Not calling you out specifically, just wondering how much thought was put into team/work structure.
I go out of my way to hire older devs that are eschewed by typical Bay Area startups. I can get a seasoned pro with a solid background in C - and other more trendy languages - for about the same price of a 3-years-working-experience "senior dev" who likely was battlefield commissioned into the role at their last startup.
The typical solid dev can only put in 4, maybe 5-6 hours of actual good coding a day. If you know how to run a tight org - and not a sweatshop of 20-year olds pulling 16 hour days where only maybe 2-3 hours are actual programming time - then older devs are a fantastic bargain. Plus, when it comes time to architect something complex, I have found older devs typically create more simple and elegant solutions just because they have been exposed to more.
Of course, I do run into the occasional stuck-in-the-mud older dev who is very slow to adapt to current trends and wants everyone else to get off their lawn. That has been a rare exception to my overall experience and I don't think it should be used to stereotype the older devs as a group.