Not Just Any Old Geek(blog.oldgeekjobs.com)
blog.oldgeekjobs.com
Not Just Any Old Geek
https://blog.oldgeekjobs.com/not-just-any-old-geek-13caa19bc187
304 comments
I wouldn't worry. We can actually Get Stuff Done, which at the end of the day is what really counts. Inexperienced young programmers working 2x the hours do not necessarily produce Output That Works (I know, I've been one myself). Sure, not every company will realize that, but then again, you don't necessarily want to work for every ping-pong table company, either. Cultural fit and all that.
I hate smug answers like this. I'm old and the young people I work with at Uber are amazing and get tons of things done. Just because you're old doesn't mean you know any better or just because they are young, it doesn't mean they can't get shit done.
Pretending that just because you're old you hold some magical advantage doesn't fly. You need to prove yourself every day because this is the industry we are in.
And the reasons why young people are more desirable is obvious. They generally have more energy, less time constraints and aren't afraid of change. I work very hard to keep myself current. But it's hard.
I have 5 side projects gathering dust at home because after work, commute and kids, I'm exhausted. It's easy to keep up when your only commitments are work and relationship.
So it's fairly obvious why younger people are more desirable. As long as companies give us old guys a chance I don't mind. I'm smart and will fight for my opportunities. I don't think I'm entitled to anything. My boss is almost 20 years younger than me but he's smart and cool. At some point this may end but that's just reality. No one hires 60 year old coal miners either when there are 20 year olds available.
Pretending that just because you're old you hold some magical advantage doesn't fly. You need to prove yourself every day because this is the industry we are in.
And the reasons why young people are more desirable is obvious. They generally have more energy, less time constraints and aren't afraid of change. I work very hard to keep myself current. But it's hard.
I have 5 side projects gathering dust at home because after work, commute and kids, I'm exhausted. It's easy to keep up when your only commitments are work and relationship.
So it's fairly obvious why younger people are more desirable. As long as companies give us old guys a chance I don't mind. I'm smart and will fight for my opportunities. I don't think I'm entitled to anything. My boss is almost 20 years younger than me but he's smart and cool. At some point this may end but that's just reality. No one hires 60 year old coal miners either when there are 20 year olds available.
Are you saying experience counts for nothing? Besides for the muscle memory of being able to knock out a script quickly, there's also the advantage of having seen weird one-off problems before.
To give a simple advantage, not really a one-off problem, but a dev was wondering why a function in his cron script wasn't working when the same function was working fine elsewhere in the application. I told him to check that cron was using the same config file as the webserver, but I only knew that because I'd seen the same thing before. No amounts of energy will give you that 'seen this before' experience. I remember the first time a server ran out of disk space really confused me - non of the logging/error messages seemed to make sense and the behaviour of the application seemed weird. It takes experience to pick up these patterns. Age isn't the best heuristic here, because a 25 year old might have 15 years experience, and a 40 year old might have picked up programming only 5 years ago, but experience counts.
> I have 5 side projects gathering dust at home because after work, commute and kids, I'm exhausted. It's easy to keep up when your only commitments are work and relationship.
That's just you. I've known young people with the same commitments of relationships and kids, and old people who could fully commit themselves to work so I don't think your point about time constraints hold.
And outside of Silicon Valley, I don't see this same enthusiasm for young people. Maybe it's the bias of the field I'm in (business software) but with age also comes industry experience independent of programming knowledge (I used to naively think automating all processes was the end goal - there are some processes that shouldn't be automated for good customer relationships). Bear in mind most successful startups are started between the ages 35-45 - source here - http://www.forbes.com/sites/krisztinaholly/2014/01/15/why-gr... - and the people who did the study attributed it to industry experience.
At the end of the day, the best filters/heuristics aren't visibly external ones like age (or race) but practical ones like discussions on theory, conversations about commitment - actual data about the subject matter.
> No one hires 60 year old coal miners either when there are 20 year olds available.
I'd definitely prefer a 60 year old doctor (I don't mean a surgeon, but a consultant), lawyer or accountant. Do you think coal mining is more similar to those or to coal mining?
To give a simple advantage, not really a one-off problem, but a dev was wondering why a function in his cron script wasn't working when the same function was working fine elsewhere in the application. I told him to check that cron was using the same config file as the webserver, but I only knew that because I'd seen the same thing before. No amounts of energy will give you that 'seen this before' experience. I remember the first time a server ran out of disk space really confused me - non of the logging/error messages seemed to make sense and the behaviour of the application seemed weird. It takes experience to pick up these patterns. Age isn't the best heuristic here, because a 25 year old might have 15 years experience, and a 40 year old might have picked up programming only 5 years ago, but experience counts.
> I have 5 side projects gathering dust at home because after work, commute and kids, I'm exhausted. It's easy to keep up when your only commitments are work and relationship.
That's just you. I've known young people with the same commitments of relationships and kids, and old people who could fully commit themselves to work so I don't think your point about time constraints hold.
And outside of Silicon Valley, I don't see this same enthusiasm for young people. Maybe it's the bias of the field I'm in (business software) but with age also comes industry experience independent of programming knowledge (I used to naively think automating all processes was the end goal - there are some processes that shouldn't be automated for good customer relationships). Bear in mind most successful startups are started between the ages 35-45 - source here - http://www.forbes.com/sites/krisztinaholly/2014/01/15/why-gr... - and the people who did the study attributed it to industry experience.
At the end of the day, the best filters/heuristics aren't visibly external ones like age (or race) but practical ones like discussions on theory, conversations about commitment - actual data about the subject matter.
> No one hires 60 year old coal miners either when there are 20 year olds available.
I'd definitely prefer a 60 year old doctor (I don't mean a surgeon, but a consultant), lawyer or accountant. Do you think coal mining is more similar to those or to coal mining?
> Pretending that just because you're old you hold some magical advantage doesn't fly
Experience is not magic, it is not directly a function of age but of duration in the industry. I'm not even tyat old yet, but my experience (aka larger training set) so far allows me to pattern-match/foresee potential disasters way before they appear on radars of more junior devs: and this goes for technology, people and processes.
> No one hires 60 year old coal miners either when there are 20 year olds available
That's because mining coal is physically exerting. I would hire a 60 year old boilermaker before any 20 year old since I don't want things to go boom.
Edit:
> just because they are young, it doesn't mean they can't get shit done.
With experience, you know which shit not to do
Experience is not magic, it is not directly a function of age but of duration in the industry. I'm not even tyat old yet, but my experience (aka larger training set) so far allows me to pattern-match/foresee potential disasters way before they appear on radars of more junior devs: and this goes for technology, people and processes.
> No one hires 60 year old coal miners either when there are 20 year olds available
That's because mining coal is physically exerting. I would hire a 60 year old boilermaker before any 20 year old since I don't want things to go boom.
Edit:
> just because they are young, it doesn't mean they can't get shit done.
With experience, you know which shit not to do
You're comparing great old people with shitty young people. I know plenty of very shitty old people and a lot of great young people that would invalidate what you said above. And in my experience there aren't very many great old people that are current with technology, that can code quickly, etc. most just want to keep doing what they're doing and earn a paycheck which is fine but then they shouldn't complain when they get replaced by younger faster models.
You might have misunderstood me. My point is experience is a great asset to any developer, young or old.
> And in my experience there aren't very many great old people that are current with technology, that can code quickly, etc.
That might mean that the great old people are either not great at these things despite their efforts (which I believe is your opinion), OR it could mean the old people optimize for the things you did not list, and don't place too a lot of value on "coding quickly", for example.
> And in my experience there aren't very many great old people that are current with technology
There older I get, the more I realize there is more to life than work. I mean, I love technology, web development particularly (because the web is awesome for humanity), I really do enjoy it. However, I can make better, more fulfilling use of (some of) my weekends and evenings than staring at my laptop, rewriting an app in LatestHypeJS. Is there any other industry that requires much running just to stay in one place?
Bear in mind the "younger faster models" won't stay young forever.
> And in my experience there aren't very many great old people that are current with technology, that can code quickly, etc.
That might mean that the great old people are either not great at these things despite their efforts (which I believe is your opinion), OR it could mean the old people optimize for the things you did not list, and don't place too a lot of value on "coding quickly", for example.
> And in my experience there aren't very many great old people that are current with technology
There older I get, the more I realize there is more to life than work. I mean, I love technology, web development particularly (because the web is awesome for humanity), I really do enjoy it. However, I can make better, more fulfilling use of (some of) my weekends and evenings than staring at my laptop, rewriting an app in LatestHypeJS. Is there any other industry that requires much running just to stay in one place?
Bear in mind the "younger faster models" won't stay young forever.
I think an interesting question is - more desirable to what end? To what end are these youths toiling? How, after millenia of evidence to the contrary indicating that experience is valuable, are we to believe that somehow magically it is not valuable? What if the end to which the young are applying themselves (or being applied) is not in fact of any value? Historically young inexperienced men have been considered entirely disposable. Perhaps now they are being disposed of in a different way?
> We can actually Get Stuff Done, which at the end of the day is what really counts
It's harder for me to "get stuff done" when then "stuff" is bullshit. There are times when what's being asked for is wrong (stealing code/images/whatever), or a wrong solution to the problem. "Right/Wrong" can be subjective, so I shy away from making those snap judgements until I know more about why something is being asked for, but after a while, you tend to develop a 6th sense for crazy.
A 23 year old in their first job will (generally) just plug away at whatever's given them. Older folks generally won't deal as well with bullshit work.
It's harder for me to "get stuff done" when then "stuff" is bullshit. There are times when what's being asked for is wrong (stealing code/images/whatever), or a wrong solution to the problem. "Right/Wrong" can be subjective, so I shy away from making those snap judgements until I know more about why something is being asked for, but after a while, you tend to develop a 6th sense for crazy.
A 23 year old in their first job will (generally) just plug away at whatever's given them. Older folks generally won't deal as well with bullshit work.
> A 23 year old in their first job will (generally) just plug away at whatever's given them. Older folks generally won't deal as well with bullshit work.
On the contrary, I've seen far too many 20 somethings that will refuse to do anything that isn't new development.
On the contrary, I've seen far too many 20 somethings that will refuse to do anything that isn't new development.
I've seen a bit of that too, but perhaps not as much as you.
I've seen loads of folks that don't know how to work with older code (and have been guilty of that myself).
Worked on a project recently where some bit of PHP was causing trouble. The answer pushed was "just build it in node!". This was pushed by people who don't know PHP, and don't know what problem was actually occurring, but hey - "move to node!" can't ever have a downside, can it? "I'm not sure what problem I'm solving, but it'll be in nodejs, so everything will be great" seems to be a common trend over the last couple of years (at least in some of the circles I travel in).
I've seen loads of folks that don't know how to work with older code (and have been guilty of that myself).
Worked on a project recently where some bit of PHP was causing trouble. The answer pushed was "just build it in node!". This was pushed by people who don't know PHP, and don't know what problem was actually occurring, but hey - "move to node!" can't ever have a downside, can it? "I'm not sure what problem I'm solving, but it'll be in nodejs, so everything will be great" seems to be a common trend over the last couple of years (at least in some of the circles I travel in).
> It's harder for me to "get stuff done" when then "stuff" is bullshit
Same here, I guess tolerance to bullshit diminishes with age. Perhaps it has to do with experience. I cringe when asked to do something that will increase technical debt because I can see what it will be like repaying that debt in the future. Younger me could not see that far.
Same here, I guess tolerance to bullshit diminishes with age. Perhaps it has to do with experience. I cringe when asked to do something that will increase technical debt because I can see what it will be like repaying that debt in the future. Younger me could not see that far.
Honestly, even as I'm getting older, this isn't at all obvious to me. Someone with five years solid experience with web development might very well be far more effective than someone with twenty years experience of working in corners of large companies with various technologies, especially when you consider the expected salary.
I think it good that people are talking about these things, but sometime it seem like people think it's a big conspiracy, rather than a factor of how the ecosystem and market looks.
I think it good that people are talking about these things, but sometime it seem like people think it's a big conspiracy, rather than a factor of how the ecosystem and market looks.
If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times?
If you were wrongly convicted and awaiting a death sentence, would you pick a 22 year old attorney fresh from law school to defend you?
If you have a field full of tomatoes that needs picking, do you save a few dollars an hour hiring the young guy at minimum wage who is healthy, has no family, and will easily work beyond maximum hours without reporting it, or do you hire the older tomato picker who needs a higher salary because of his kids and can't work more than 7.5 hours a day because of his bad back?
So are we law and medicine or are we tomato pickers? I had always thought of engineering as the former but sadly the more articles I see on how "culture fit" discrimination works, maybe we've commoditized the industry into a low wage manual labor job.
If you were wrongly convicted and awaiting a death sentence, would you pick a 22 year old attorney fresh from law school to defend you?
If you have a field full of tomatoes that needs picking, do you save a few dollars an hour hiring the young guy at minimum wage who is healthy, has no family, and will easily work beyond maximum hours without reporting it, or do you hire the older tomato picker who needs a higher salary because of his kids and can't work more than 7.5 hours a day because of his bad back?
So are we law and medicine or are we tomato pickers? I had always thought of engineering as the former but sadly the more articles I see on how "culture fit" discrimination works, maybe we've commoditized the industry into a low wage manual labor job.
>If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times?
If you were hiring, you would want the starry eyed, finger in the pulse of latest fads, young programmer you can pay less, overwork, boss around, and screw over, or the senior engineer, who values sane hours and time with family, doesn't blindly adopt any BS fad technology you want them to use, and demands salary that matches their experience?
Especially if the first can still get out something that "kinda works" and you could not give a rats arse about technical debt and bad decisions behind the UI facade?
If you were hiring, you would want the starry eyed, finger in the pulse of latest fads, young programmer you can pay less, overwork, boss around, and screw over, or the senior engineer, who values sane hours and time with family, doesn't blindly adopt any BS fad technology you want them to use, and demands salary that matches their experience?
Especially if the first can still get out something that "kinda works" and you could not give a rats arse about technical debt and bad decisions behind the UI facade?
Soooo.... Tomato pickers it is! :-)
Good counterpoint, liked both this and the grandparent comment. Ouch.
Good counterpoint, liked both this and the grandparent comment. Ouch.
If that's what the hiring person is like, though, I'm fine with not getting that job...
As long as there are enough other good programming gigs available though...
As in, most McDonalds workers also hate both the hiring person AND the job, but they do it anyway.
As in, most McDonalds workers also hate both the hiring person AND the job, but they do it anyway.
- until that's _all_ there is.
Weirdly, the mortality rates from surgeries can go up with much older doctors, for a variety of reasons, but mostly because they have lower volume of work so aren't as in practice and may not be current on latest techniques that may be less invasive or higher success rate. It could also be older people like having older doctors and the mortality rate is higher with older people getting surgery.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1856535/
There is probably a statistical sweet spot, where someone has years of experience, is active enough to be up on the latest techniques, or at least learns the new techniques and adopts them. Parallels can be drawn between this and tech workers I'm sure.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1856535/
There is probably a statistical sweet spot, where someone has years of experience, is active enough to be up on the latest techniques, or at least learns the new techniques and adopts them. Parallels can be drawn between this and tech workers I'm sure.
The vast majority of software engineering work does not have the same rigor that other fields of engineering do. Standards, safety, inspection, accountability, documentation, testing, certification, etc... many other fields focus on these things, but in software it's pretty much "anything goes so long as we make money." The trick to making companies value good engineers is getting them to value good engineering.
Churning out code usually isn't engineering, and it isn't tomato picking. It's more like being a machinist in an industrial setting. You need to know the tools and how to read the spec. That's why you can post a technology position, get 1,000 resumes from people working professionally, and find that 80% of the candidates lack basic knowledge.
The problem is that if you don't up your game to be in a more engineering-y role, you're just one ROI calculation away from being automated out of existence.
The problem is that if you don't up your game to be in a more engineering-y role, you're just one ROI calculation away from being automated out of existence.
Umm the more comparable parable would be "or the proverbial graybeard who has done ~~it~~ kidney surgery a thousand times"
The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. Like holly shit most people weren't even using source control back, unit testing and automated testing in general was SciFi, it was done by QA departments if you were big enough to do it.
People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles.
Security was abysmal - you didn't even have process isolation on OS-es.
The languages and the practices are also completely different - disregarding the "we did it in the 60s with LISP in this paper" crowd - outside of academia people were just getting in to the OOP which was the pinnacle of abstractions back then.
This is the drag&drop and copy-paste as an abstraction VB shit era.
Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics.
The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. Like holly shit most people weren't even using source control back, unit testing and automated testing in general was SciFi, it was done by QA departments if you were big enough to do it.
People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles.
Security was abysmal - you didn't even have process isolation on OS-es.
The languages and the practices are also completely different - disregarding the "we did it in the 60s with LISP in this paper" crowd - outside of academia people were just getting in to the OOP which was the pinnacle of abstractions back then.
This is the drag&drop and copy-paste as an abstraction VB shit era.
Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics.
Stuff that hasnt changed markedly: geometry math, statistics. SQL - 1970s. SOLID - parts of that are late 1980. C still looks like C. Unix like environments. Awk/sed/etc.
Go read about the history of the web or XML; you get a very strong sense that these things have been thought about for a long time - data interchange has varied formats, but there is still a lot of tedious ETL type work. The importance of naming things well hasnt changed. Identifiers for data being a hard thing hasnt changed. Schema/vocabularies and more are still important problems.
If you cant see some of these things underpinning much of the work we do, you might be missing the forest for the trees
Go read about the history of the web or XML; you get a very strong sense that these things have been thought about for a long time - data interchange has varied formats, but there is still a lot of tedious ETL type work. The importance of naming things well hasnt changed. Identifiers for data being a hard thing hasnt changed. Schema/vocabularies and more are still important problems.
If you cant see some of these things underpinning much of the work we do, you might be missing the forest for the trees
One thing I've found that's significantly changed since I began my career, before my beard went grey, is that projects are now in general run much better. People never make a total mess of estimating timings, and the Agile methodology (and Kanban boards, and Trello, and JIRA, and of course Slack) really fix all organisational and prioritisation problems such that projects never end in disaster; gone are the days of frantic last minute firefighting and all-nighters, as we desperately work out which features are critical to getting the project live before everything explodes. Clearly the experience of older, wiser heads in moments of crisis is now basically never required because projects run so smoothly.
Haha, sorry, I'm only kidding.
Haha, sorry, I'm only kidding.
Most programs don't really use algorithms or data structures that were discovered much later than the '70s. This idea that old experience is worthless because we're using different libraries now strikes me as altogether wrongheaded.
The stuff you learned in your CS course is still just as relevant as it was 20 years ago. The things you did in your development career are nowhere near so.
Did you use SCM, automated testing and design patterns 20 years ago ? If yes do you think this was the norm in the industry ?
I'm not saying those things are the only relevant things, I'm just pointing out the obvious examples of how much things have changed since then. I've said in another comment, we've moved from mainframe/single PC shared memory model in to distributed/cloud/networked computing in the last 20 years and the problems from that era are completely different to problems today. Even on the low-level end the basic design constraints such as the difference between CPU instruction speed/memory access/cache miss dramatically changed what it means to write optimized code, nobody these days rolls their own SQRT function to squeeze out a few extra CPU cycles, now days it's about making sure your memory is laid out so that you get as few cache misses as possible.
Did you use SCM, automated testing and design patterns 20 years ago ? If yes do you think this was the norm in the industry ?
I'm not saying those things are the only relevant things, I'm just pointing out the obvious examples of how much things have changed since then. I've said in another comment, we've moved from mainframe/single PC shared memory model in to distributed/cloud/networked computing in the last 20 years and the problems from that era are completely different to problems today. Even on the low-level end the basic design constraints such as the difference between CPU instruction speed/memory access/cache miss dramatically changed what it means to write optimized code, nobody these days rolls their own SQRT function to squeeze out a few extra CPU cycles, now days it's about making sure your memory is laid out so that you get as few cache misses as possible.
> Did you use SCM, automated testing and design patterns 20 years ago ? If yes do you think this was the norm in the industry ?
Design patterns are way older than 20 years... hell, the design pattern bible was published 22 years ago, which means design patterns were in wide circulation well before I could tie shoes. According to wikipedia CVS has been around for 26 years.
Design patterns are way older than 20 years... hell, the design pattern bible was published 22 years ago, which means design patterns were in wide circulation well before I could tie shoes. According to wikipedia CVS has been around for 26 years.
> According to wikipedia CVS has been around for 26 years.
Not to mention SCCS for 44 years, and RCS for 34.
Not to mention SCCS for 44 years, and RCS for 34.
Again - I'm not saying these things didn't exist - I'm saying they weren't the norm in the industry.
You're saying a lot of things, without stopping to check whether you're right or not.
Even though I am ony 25 I can recognize that all the computing foundations is still the same. I work in a 80's style company deving embedded system and I constantly talk with the founders who used to program the first system we used to sell. They used to implement everything from scratch. Sharing code, open source stuffs and Internet are making our life easier. But at the end of the they the knowledge behind the libraries, frameworks used in the library is the same from the early times.
I picked up the CVS habit almost exactly 20 years ago (1996) from someone in the banking & finance industry -- hardly a bastion of radical adoption. By then, CVS was 10 years old. We used RCS extensively to manage config files.
To the earlier parent who mentioned process isolation: You're thinking too much about the consumer/desktop world. The entire enterprise world was used to it and demanded it, be it on (hey, humor here) SCO UNIX (yes, they really did make a useful product before they turned evil), SunOS, VAX/VMS, MVS, BSD UNIX, etc.
The desktop world was far behind the state of the art in commercial systems in those days. Even in the 80s, you were quite possibly running your enterprise with an Oracle database, on fully memory-protected hardware. Heck - you may have even been running some of your stuff in a VM on an IBM mainframe. We took some big jumps backwards in pursuit of making computers cost-effective enough for mass adoption, and it took a while before the consumer side of things jumped forward to become the same platforms used for enterprise use.
Kids these days. ;)
To the earlier parent who mentioned process isolation: You're thinking too much about the consumer/desktop world. The entire enterprise world was used to it and demanded it, be it on (hey, humor here) SCO UNIX (yes, they really did make a useful product before they turned evil), SunOS, VAX/VMS, MVS, BSD UNIX, etc.
The desktop world was far behind the state of the art in commercial systems in those days. Even in the 80s, you were quite possibly running your enterprise with an Oracle database, on fully memory-protected hardware. Heck - you may have even been running some of your stuff in a VM on an IBM mainframe. We took some big jumps backwards in pursuit of making computers cost-effective enough for mass adoption, and it took a while before the consumer side of things jumped forward to become the same platforms used for enterprise use.
Kids these days. ;)
Can I ask how old you are? And if you are below 25, which I think you are, judging by your comments, then how do you know?
> Did you use SCM, automated testing and design patterns 20 years ago ? If yes do you think this was the norm in the industry ?
Just because people did not use a standalone program for version control does not mean that they did not version their code. This goes all the way back to card/tape drawers and paper tape revisions (there is a great anecdote about this in Steven Levy's Hackers). Look at software from the late 1970s/early 1980s - there will be versioning information there, and usually changelogs describing what was changed. A lot of operating systems also had file versioning built into the filesystem (https://en.wikipedia.org/wiki/Versioning_file_system#Impleme...) that was used for revision control. Since most of these OSes were timesharing systems this was in effect team-based version control.
Just because people did not use a standalone program for version control does not mean that they did not version their code. This goes all the way back to card/tape drawers and paper tape revisions (there is a great anecdote about this in Steven Levy's Hackers). Look at software from the late 1970s/early 1980s - there will be versioning information there, and usually changelogs describing what was changed. A lot of operating systems also had file versioning built into the filesystem (https://en.wikipedia.org/wiki/Versioning_file_system#Impleme...) that was used for revision control. Since most of these OSes were timesharing systems this was in effect team-based version control.
> Did you use SCM, automated testing and design patterns 20 years ago ? If yes do you think this was the norm in the industry ?
SCM was the norm, at least in certain circles, maybe you should read up on stuff as:
https://en.wikipedia.org/wiki/IBM_Software_Configuration_and...
https://en.wikipedia.org/wiki/Source_Code_Control_System
Now of course, many PC developers came from 8-bit computers rather than mainframes, where SCM didn't really mattered, because programs were very small.
Automated testing - well, I have seen Lisp compiler written in the 80s that had them. So where it made sense and was possible to do, I think people did it. (IMHO it only makes sense for programs or their parts that are written in purely functional style, which is not a big chunk.) The workflow was different in the past (big emphasis on integration and system testing) and I wouldn't say it was necessarily worse.
Design patterns definitely existed, but they weren't named as such.
I am not even sure if people (writing business applications) are more productive today. We have lot of new artificial requirements. In the past, it was typical for datatypes and other things to be constrained by design. Today, people are unwilling to do that, even though it wouldn't change anything from the business perspective.
Or take a look at web. It's a tangled mess of HTML, CSS and JS (it's been 20 years and people still can't agree whether or not is a good idea to produce HTML in JS!). In the past, you would use something like CICS or VB or Delphi, which is a consistent framework, written for the purpose of building interactive business application.
> we've moved from mainframe/single PC shared memory model in to distributed/cloud/networked computing in the last 20 years and the problems from that era are completely different to problems today
Not really. The tradeoffs are simple to understand for somebody who had CS course 20, or even 40 years ago. And even back then people writing applications didn't hand roll their own SQRT, even back then frameworks and libraries did that for you.
SCM was the norm, at least in certain circles, maybe you should read up on stuff as:
https://en.wikipedia.org/wiki/IBM_Software_Configuration_and...
https://en.wikipedia.org/wiki/Source_Code_Control_System
Now of course, many PC developers came from 8-bit computers rather than mainframes, where SCM didn't really mattered, because programs were very small.
Automated testing - well, I have seen Lisp compiler written in the 80s that had them. So where it made sense and was possible to do, I think people did it. (IMHO it only makes sense for programs or their parts that are written in purely functional style, which is not a big chunk.) The workflow was different in the past (big emphasis on integration and system testing) and I wouldn't say it was necessarily worse.
Design patterns definitely existed, but they weren't named as such.
I am not even sure if people (writing business applications) are more productive today. We have lot of new artificial requirements. In the past, it was typical for datatypes and other things to be constrained by design. Today, people are unwilling to do that, even though it wouldn't change anything from the business perspective.
Or take a look at web. It's a tangled mess of HTML, CSS and JS (it's been 20 years and people still can't agree whether or not is a good idea to produce HTML in JS!). In the past, you would use something like CICS or VB or Delphi, which is a consistent framework, written for the purpose of building interactive business application.
> we've moved from mainframe/single PC shared memory model in to distributed/cloud/networked computing in the last 20 years and the problems from that era are completely different to problems today
Not really. The tradeoffs are simple to understand for somebody who had CS course 20, or even 40 years ago. And even back then people writing applications didn't hand roll their own SQRT, even back then frameworks and libraries did that for you.
The design pattern book came out 22 years ago so they were certainly named as such.
My first Unix programming job had me first learn RCS and then we later switched to CVS. I used CVS personally for years after that until I switched to Subversion, then Mercurial, and now Git. What I'm doing isn't that different from when I used RCS. There's more steps because of the added complexity but it's roughly similar.
My first Unix programming job had me first learn RCS and then we later switched to CVS. I used CVS personally for years after that until I switched to Subversion, then Mercurial, and now Git. What I'm doing isn't that different from when I used RCS. There's more steps because of the added complexity but it's roughly similar.
"nobody these days rolls their own SQRT function to squeeze out a few extra CPU cycles"
Um, nobody did this 20 years ago, either.
Um, nobody did this 20 years ago, either.
https://en.wikipedia.org/wiki/Fast_inverse_square_root
Not exactly SQRT, but.
Not exactly SQRT, but.
Also an incredibly specialized case and in those kinds of extremely performance-intensive scenarios it might still make sense.
I was in high school and didn't know the first thing about programming 20 years ago. But it seems to me that "design patterns," SCM, and automated testing aren't the hard part of this discipline.
Sure they are. They are the "hard part" of what every 9-5 LOB dev has to do, and even in the more CS heavy fields from my experience the algorithms and the fancy CS is 20% of the work and the rest is implementing mundane details, bug fixing, testing, cooperating with team members, etc. And that's the stuff that improved since the 90s.
Delivering reliable software is hard - but we've gotten a lot better at it in the last 20 years, if you don't believe me boot up some old windows 95/98 image install some random software and see for yourself.
Delivering reliable software is hard - but we've gotten a lot better at it in the last 20 years, if you don't believe me boot up some old windows 95/98 image install some random software and see for yourself.
We also do a lot of typing but nobody's arguing that that should be the primary yardstick by which we measure.
I wasn't in high school 20 years ago; I wasn't even ten. I dunno why I said that. Whoops.
Hmmm ... disagree!
18 years ago we had much of what we had today. Things might move on but they do not change. I mean hey, everyone still hates Visual Basic!
At least 18 years ago we were actually writing the majority of our code rather than relying so heavily on libraries and third party code. I mean someone only has to pull a Node.js plugin for padding and there is complete melt down!
18 years ago we had much of what we had today. Things might move on but they do not change. I mean hey, everyone still hates Visual Basic!
At least 18 years ago we were actually writing the majority of our code rather than relying so heavily on libraries and third party code. I mean someone only has to pull a Node.js plugin for padding and there is complete melt down!
If the parent is sarcasm, please disregard my reply.
> The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today.
Not even remotely true. Most of computer science is built on the past and either composed into something new upon a previous foundation, or a poor re-implementation of an already existing idea. A trendy favorite of many at the moment, Go lang is a good example of the former. For instance, CSP used in Go (and Clojure) is definitely not a new idea and has everything to do with what we do today. Another example is data structures - not sure what you're doing if you aren't using these, but the most common ones were invented long ago and most newer things I see are just refinements, additions, or behavioral changes on what existed before.
Speaking of Clojure, functional programming and Lisp are additional examples of old things "we" used to do in software 20+ years ago and are very much relevant today. You are making blanket statements about research, practices, and more here. It's true that Lisp was not widely used in many circles, but there are numerous reasons for that beyond what you mention, many of which were not good ones. Many people outside academia used a lot of old concepts successfully or otherwise knew they were good but had other limited factors, most commonly hardware or market share.
I encourage anyone "inventing" anything new to simply dig through old research whether it is 60s Lisp weeny stuff as you describe or Plan9 or anything else before you think you invented something. 99% of the time someone has at least researched it, written about it, and maybe even implemented it better than you will. Timing is often everything, as are other factors like technological resources (hardware, people, market skills, etc.). Computer science, like many fields, excels at reinventing things poorly. It usually comes down to thinking before acting as very few of us are both smart enough and talented enough to produce something properly acting on impulses and limited knowledge alone.
> This is the drag&drop and copy-paste as an abstraction VB shit era.
And this has changed how? Look at what a lot of people use Google and Stackoverflow to do. Of course these tools are great, but so was the VB GUI designer. It's how you use it and who is using it. We have far more copy-paste style tools than ever before and far more languages that are suited to producing unmaintainable spider webs of awful.
> People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles.
What are you doing now? People are still doing this constantly, not only for embedded programming but for games, apps, everything. Just about every month there are multiple posts on HN about people patting themselves on the back for shaving memory and CPU cycles off their code on a new platform and/or running on something like commodity hardware. I know you want to say hardware wasn't as good, but it's also been my experience less people know how to manage performance properly and we still spend a lot of time cleaning up messes, only they are on the gigabyte level instead of the byte level.
> Security was abysmal - you didn't even have process isolation on OS-es.
Not all OSs worked this way. True, the popular ones were often pretty bad. They are still not good and with more stuff accessible faster remotely, even more malicious actors, and bigger consequences, the situation is arguably worse.
> Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics.
The same holds true today. If you only do one thing, you won't be good at programming except perhaps in that narrow field if you are lucky. If anything, it's been my observation that far less people know what they are doing as the barriers to entry into the field have gone down. Not everyone who once upon a time wrote C, COBOL, Lisp, Fortran, or whatever else learned nothing along the way. Plenty of people pivot and do amazing things.
Overall, it sounds to me you are the one who lacks the depth and breadth of experience. You need to meet more people, keep an open mind, and do research before you make judgement. Moreover, you need to avoid blanket statements (appreciate the irony).
> The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today.
Not even remotely true. Most of computer science is built on the past and either composed into something new upon a previous foundation, or a poor re-implementation of an already existing idea. A trendy favorite of many at the moment, Go lang is a good example of the former. For instance, CSP used in Go (and Clojure) is definitely not a new idea and has everything to do with what we do today. Another example is data structures - not sure what you're doing if you aren't using these, but the most common ones were invented long ago and most newer things I see are just refinements, additions, or behavioral changes on what existed before.
Speaking of Clojure, functional programming and Lisp are additional examples of old things "we" used to do in software 20+ years ago and are very much relevant today. You are making blanket statements about research, practices, and more here. It's true that Lisp was not widely used in many circles, but there are numerous reasons for that beyond what you mention, many of which were not good ones. Many people outside academia used a lot of old concepts successfully or otherwise knew they were good but had other limited factors, most commonly hardware or market share.
I encourage anyone "inventing" anything new to simply dig through old research whether it is 60s Lisp weeny stuff as you describe or Plan9 or anything else before you think you invented something. 99% of the time someone has at least researched it, written about it, and maybe even implemented it better than you will. Timing is often everything, as are other factors like technological resources (hardware, people, market skills, etc.). Computer science, like many fields, excels at reinventing things poorly. It usually comes down to thinking before acting as very few of us are both smart enough and talented enough to produce something properly acting on impulses and limited knowledge alone.
> This is the drag&drop and copy-paste as an abstraction VB shit era.
And this has changed how? Look at what a lot of people use Google and Stackoverflow to do. Of course these tools are great, but so was the VB GUI designer. It's how you use it and who is using it. We have far more copy-paste style tools than ever before and far more languages that are suited to producing unmaintainable spider webs of awful.
> People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles.
What are you doing now? People are still doing this constantly, not only for embedded programming but for games, apps, everything. Just about every month there are multiple posts on HN about people patting themselves on the back for shaving memory and CPU cycles off their code on a new platform and/or running on something like commodity hardware. I know you want to say hardware wasn't as good, but it's also been my experience less people know how to manage performance properly and we still spend a lot of time cleaning up messes, only they are on the gigabyte level instead of the byte level.
> Security was abysmal - you didn't even have process isolation on OS-es.
Not all OSs worked this way. True, the popular ones were often pretty bad. They are still not good and with more stuff accessible faster remotely, even more malicious actors, and bigger consequences, the situation is arguably worse.
> Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics.
The same holds true today. If you only do one thing, you won't be good at programming except perhaps in that narrow field if you are lucky. If anything, it's been my observation that far less people know what they are doing as the barriers to entry into the field have gone down. Not everyone who once upon a time wrote C, COBOL, Lisp, Fortran, or whatever else learned nothing along the way. Plenty of people pivot and do amazing things.
Overall, it sounds to me you are the one who lacks the depth and breadth of experience. You need to meet more people, keep an open mind, and do research before you make judgement. Moreover, you need to avoid blanket statements (appreciate the irony).
Like I've said the stuff that hasn't changed much is the CS, the actual engineering part has nothing to do with what we do today. 20 years ago the net was nowhere nearly as ubiquitous, hardware was incomparably slow, the bottlenecks were different - the focus shifted from single computer/mainframes/shared memory models -> distributed computing.
When I say copy paste in visual basic I'm talking about professional programmers that couldn't even abstract stuff in to functions but would copy paste shit all over the code - not copy-pasting from other sources.
As much as people like to bitch about our industry we have heavily increased engineering standard, if you don't use source control these days you get laughed at, if you don't use automated testing you're an amateur, even junior programmers know about patterns and nobody copy-pastes code over their code base - stuff like this was the exception back then not the norm as it is now. You can say MVC was invented in the 80s or w/e but up until maybe 10 years ago the internet was full of tutorials/guides on how to do web coding by interpolating PHP inside of your HTML, using string concatenation to build SQL queries and such nonsense. Sure top 10% never did that but the vast majority of programmers did and the broader industry has improved significantly since then, in no small part thanks to the frameworks that constrain the bad developers on to the "good path".
When I say copy paste in visual basic I'm talking about professional programmers that couldn't even abstract stuff in to functions but would copy paste shit all over the code - not copy-pasting from other sources.
As much as people like to bitch about our industry we have heavily increased engineering standard, if you don't use source control these days you get laughed at, if you don't use automated testing you're an amateur, even junior programmers know about patterns and nobody copy-pastes code over their code base - stuff like this was the exception back then not the norm as it is now. You can say MVC was invented in the 80s or w/e but up until maybe 10 years ago the internet was full of tutorials/guides on how to do web coding by interpolating PHP inside of your HTML, using string concatenation to build SQL queries and such nonsense. Sure top 10% never did that but the vast majority of programmers did and the broader industry has improved significantly since then, in no small part thanks to the frameworks that constrain the bad developers on to the "good path".
If you don't use source control these days, you're below average.
If you don't use automated testing, you are probably average.
Plenty of junior programmers know nothing about patterns except how to cargo-cult them.
Plenty of people copy-paste code everywhere.
I'm curious how long you've been doing this stuff, because this sounds like neophilia.
If you don't use automated testing, you are probably average.
Plenty of junior programmers know nothing about patterns except how to cargo-cult them.
Plenty of people copy-paste code everywhere.
I'm curious how long you've been doing this stuff, because this sounds like neophilia.
I'll give you that the tooling is quite a bit better these days, but that's it. Practices are as horrid as ever. Cut-pasting from Stack Overflow seems like something every new grad knows how to do, and is everywhere. Not sure about your focus on design patterns--I'd often call their use a negative, not a positive. When faced with a problem, a good developer asks, "How can I solve this?" A bad developer asks, "I must find some named design pattern to mash this problem into."
At its core, 90% of professional programming is:
1. Plumbing: Routing data from this component to that one through this API
2. Processing: Algorithms, most which have been published for decades)
3. Formatting: Ingesting data in format A and displaying it for the user in format B.
This is true today, was true when I started, and was true 20 years before that.
At its core, 90% of professional programming is:
1. Plumbing: Routing data from this component to that one through this API
2. Processing: Algorithms, most which have been published for decades)
3. Formatting: Ingesting data in format A and displaying it for the user in format B.
This is true today, was true when I started, and was true 20 years before that.
"When I say copy paste in visual basic I'm talking about professional programmers that couldn't even abstract stuff in to functions but would copy paste shit all over the code - not copy-pasting from other sources."
The inability to use abstractions properly has long been a sign of inexperience or incompetence. I'd really like to see some evidence that this was any more prevalent in 1996 than it is in 2016.
There's definitely more of a concern these days in the general programming world about "best practices". But those best practices weren't invented yesterday. They're usually incremental changes of older practices, and the results of bitter, painful experience of doing things the "wrong" way. Exactly the kind of experience that senior engineers have that junior engineers lack. It's senior engineers who create those best practices in the first place.
The inability to use abstractions properly has long been a sign of inexperience or incompetence. I'd really like to see some evidence that this was any more prevalent in 1996 than it is in 2016.
There's definitely more of a concern these days in the general programming world about "best practices". But those best practices weren't invented yesterday. They're usually incremental changes of older practices, and the results of bitter, painful experience of doing things the "wrong" way. Exactly the kind of experience that senior engineers have that junior engineers lack. It's senior engineers who create those best practices in the first place.
We don't really have many true standards, just pockets of consensus on best practices and collections of so-called standards that are quite often ignored. Thanks to better communication, I think it's safe to agree that these practices are more widespread. As a result, yes, quality for certain groups has definitely increased.
I think you underestimate the fact that a large number of people actually do not follow these practices, even those that know better. Further, it's hard to make statements about software quality, especially with so many moving variables like the increase in the total amount of people in the industry and lower barriers to entry. Regarding best practices, I am sure many people have stories about asking questions in interviews about a company's software development, only to be told, "Well we'd love to do X, but we just don't have the resources or time, so we do Y." Even people who know better do otherwise in addition to those that are ignorant.
I think at a conceptual level, many things have not changed. There have always been sets of new ideas and practices that people adopted, many times blindly. These are of course a mixed bag, but many so-called "best practices" are often abandoned later - fads are the norm, and while that's sometimes OK, it does not always result in "better" as much as "different." I think some people fail to realize that in the moment, it's all happened before, and all will happen again. We both learn from our past mistakes with new trends and repeat those mistakes.
MVC and frameworks are actually interesting examples. I don't want to get too into individual tech discussions, but I've personally seen people handcuff themselves trying to religiously implement things such as MVC and actually failing because of a pattern like that since they were distracted from solving the problems properly. Adopting a pattern or framework does not automatically produce better code and can even lead you the opposite way. It's hard to say if things like this are a win for all so much as if they are simply a good fit for certain problems, and therein lies the challenge and one that hasn't become easier. The golden hammer or wrong tool will forever be problems.
Frameworks often are oversold and are not standards. In fact I've found that for many projects I have actually had to abandon a particular framework long-term because it was just getting in the way for various reasons - performance, maintainability, velocity of change, conceptual failings, zealotry, etc. Frameworks can derail "bad" developers as you call them just as much as good ones. Frameworks often explode if you don't do things the "one true way" and "bad" developers can be argued to be prone to that just as much as everyone else, and simply adhering to these rules still doesn't always produce better software. There have always been frameworks in one shape or form, but they didn't always have names, sometimes they were just the language or tool imposing its constraints, sometimes for the best, sometimes the worst. As a counterpoint, I've actually found working in various languages like Clojure, Lisp, and Racket that tend to value composition of tools and functions over frameworks more productive, however I would never apply this to all projects and situations.
I see what you're getting overall at and on some level I agree. I was around in the 80s, and I don't want to go back to that. At the same time, for all the old problems solved, I see new ones that arise along with other things that were never problems coming to haunt us. It sounds like your experience is very compartmentalized to web development and you're projecting those views on to both the past and present. People are people, and no time, technologies, or tools will fix that, just deal you different cards.
I think you underestimate the fact that a large number of people actually do not follow these practices, even those that know better. Further, it's hard to make statements about software quality, especially with so many moving variables like the increase in the total amount of people in the industry and lower barriers to entry. Regarding best practices, I am sure many people have stories about asking questions in interviews about a company's software development, only to be told, "Well we'd love to do X, but we just don't have the resources or time, so we do Y." Even people who know better do otherwise in addition to those that are ignorant.
I think at a conceptual level, many things have not changed. There have always been sets of new ideas and practices that people adopted, many times blindly. These are of course a mixed bag, but many so-called "best practices" are often abandoned later - fads are the norm, and while that's sometimes OK, it does not always result in "better" as much as "different." I think some people fail to realize that in the moment, it's all happened before, and all will happen again. We both learn from our past mistakes with new trends and repeat those mistakes.
MVC and frameworks are actually interesting examples. I don't want to get too into individual tech discussions, but I've personally seen people handcuff themselves trying to religiously implement things such as MVC and actually failing because of a pattern like that since they were distracted from solving the problems properly. Adopting a pattern or framework does not automatically produce better code and can even lead you the opposite way. It's hard to say if things like this are a win for all so much as if they are simply a good fit for certain problems, and therein lies the challenge and one that hasn't become easier. The golden hammer or wrong tool will forever be problems.
Frameworks often are oversold and are not standards. In fact I've found that for many projects I have actually had to abandon a particular framework long-term because it was just getting in the way for various reasons - performance, maintainability, velocity of change, conceptual failings, zealotry, etc. Frameworks can derail "bad" developers as you call them just as much as good ones. Frameworks often explode if you don't do things the "one true way" and "bad" developers can be argued to be prone to that just as much as everyone else, and simply adhering to these rules still doesn't always produce better software. There have always been frameworks in one shape or form, but they didn't always have names, sometimes they were just the language or tool imposing its constraints, sometimes for the best, sometimes the worst. As a counterpoint, I've actually found working in various languages like Clojure, Lisp, and Racket that tend to value composition of tools and functions over frameworks more productive, however I would never apply this to all projects and situations.
I see what you're getting overall at and on some level I agree. I was around in the 80s, and I don't want to go back to that. At the same time, for all the old problems solved, I see new ones that arise along with other things that were never problems coming to haunt us. It sounds like your experience is very compartmentalized to web development and you're projecting those views on to both the past and present. People are people, and no time, technologies, or tools will fix that, just deal you different cards.
Yea I think I agree with what you said, especially that the increased communication helped this (I remember when I started programming I didn't have access to internet and once I actually got it it was a complete game changer in terms of learning).
And don't get me wrong I don't think what we have today is anywhere near perfect or even good, frameworks are often more trouble than worth but at least frameworks showed people that <?php mysql_query("select * from foo where id='" . $_GET["id"] . "'") ?> isn't the only way to write code - I do not want to go back to those days.
And don't get me wrong I don't think what we have today is anywhere near perfect or even good, frameworks are often more trouble than worth but at least frameworks showed people that <?php mysql_query("select * from foo where id='" . $_GET["id"] . "'") ?> isn't the only way to write code - I do not want to go back to those days.
I've been programming in functional languages for twelve years and recognizably modern C++ for fifteen at this point. And yet, I'm not a graybeard; I'm 28. But what I learned at that point still informs what I do today. And it's why I respect that those graybeards' old work still has impact today.
> The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today.
This is basically false in every way it's possible to be false.
This is basically false in every way it's possible to be false.
> The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today.
The longer I'm in software the more and more I find this not to be true. The stuff that has changed is all surface level. The underlying principles are the same. The skills needed are the same. The attention to detail and other attributes needed to get the job done is the same. The problems are basically recycled or scaled up versions of the problems we had years ago.
The longer I'm in software the more and more I find this not to be true. The stuff that has changed is all surface level. The underlying principles are the same. The skills needed are the same. The attention to detail and other attributes needed to get the job done is the same. The problems are basically recycled or scaled up versions of the problems we had years ago.
There's new stuff that's a significant advance (machine learning that really works), there's stuff that's just different (like most of the web backend technologies), and there's stuff that's worse (security).
[deleted]
>The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. Like holly shit most people weren't even using source control back, unit testing and automated testing in general was SciFi, it was done by QA departments if you were big enough to do it.
That stuff a competent graybeard knows already.
You don't think they disappeared in 1990 and re-appeared magically today, or that they didn't kept up with the times during their career, right?
In addition, they would know all the solid stuff -- the things programmers before the internet had to learn the hard way, and lots of today's dilettantes lack.
And you must be very young (20 something?) if you really believe that "the stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today". That's simply not true -- and triply not true for 15 years ago.
That stuff a competent graybeard knows already.
You don't think they disappeared in 1990 and re-appeared magically today, or that they didn't kept up with the times during their career, right?
In addition, they would know all the solid stuff -- the things programmers before the internet had to learn the hard way, and lots of today's dilettantes lack.
And you must be very young (20 something?) if you really believe that "the stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today". That's simply not true -- and triply not true for 15 years ago.
I mean if you were a good dev in the 90s chances are right now you're in some senior architect/management/consultant position. If you're competing for the same jobs as 20 something devs then you've probably screwed up somewhere in your career.
I started programming in late 90s but not professionally until 2006 I think, this was probably the late phase of transition to internet as a dominant factor in computing - so I think it gave me enough perspective as to how things changed, plus talking to older developers, reading stuff online and on the forums I know we've come a loong way as an industry.
I started programming in late 90s but not professionally until 2006 I think, this was probably the late phase of transition to internet as a dominant factor in computing - so I think it gave me enough perspective as to how things changed, plus talking to older developers, reading stuff online and on the forums I know we've come a loong way as an industry.
>I mean if you were a good dev in the 90s chances are right now you're in some senior architect/management/consultant position. If you're competing for the same jobs as 20 something devs then you've probably screwed up somewhere in your career.
Or you just don't like management / like programming?
Or you just don't like management / like programming?
My last two jobs I got hired for, I said while interviewing that it was my explicit career goal to never become a manager.
Yeah, I had some chances, but never liked the role of the pointy haired boss.
On the other hand, I don't like having to suffer stupid enterprise project managers either, though in my line of work it's better than the norm (more startup-y -- heck, we are at 100 people or so and our founder/boss still codes like crazy, same for the CTO).
I think the ideal for our kind of persons is having your own company -- either an one person one, or a bigger outfit but with someone else handling the marketing and finance parts. You get to both program and chose what and how to deliver.
On the other hand, I don't like having to suffer stupid enterprise project managers either, though in my line of work it's better than the norm (more startup-y -- heck, we are at 100 people or so and our founder/boss still codes like crazy, same for the CTO).
I think the ideal for our kind of persons is having your own company -- either an one person one, or a bigger outfit but with someone else handling the marketing and finance parts. You get to both program and chose what and how to deliver.
Typical ageist bullshit. Your argument is if someone is good at something then they are probably not doing it anymore. Newsflash, you were moved out of dev because you have some issue. Most people avoid "architects" which is code for cranky bastard who can't be fired but is likely breaking lots of stuff in the codebase and generally making things bad for the devs of all ages.
I guess latest code review didn't go well ?
"I mean if you were a good dev in the 90s chances are right now you're in some senior architect/management/consultant position. If you're competing for the same jobs as 20 something devs then you've probably screwed up somewhere in your career."
Not everybody's interested in climbing the corporate ladder or in architecture, management, or consulting. Some people are content to be senior engineers.
"we've come a loong way as an industry"
The industry has certainly changed a lot, but if you keep your skills up to date, that's not going to be an issue.
Not everybody's interested in climbing the corporate ladder or in architecture, management, or consulting. Some people are content to be senior engineers.
"we've come a loong way as an industry"
The industry has certainly changed a lot, but if you keep your skills up to date, that's not going to be an issue.
[deleted]
I see the opposite, rehashes of old ideas rebranded as the latest new hottness. NoSQL was basically what everyone was doing before relational databases came along. Clojure is a Lisp dialect running on the JVM. ORM's are great until you need some complex query, then it helps to know SQL. Algorithmic complexities are the same whether you were squeezing things into a tiny underpowered computer or if you are dealing with terrabytes of data.
Security was abysmal probably because there were nowhere near as many threats.
Some things change. None of it goes away.
Security was abysmal probably because there were nowhere near as many threats.
Some things change. None of it goes away.
you would actually be surprised how things are the same. You just can't see it because you didn't experience it and than you are confusing transferable knowledge with tools knowledge. Latter is easy , anybody can learn new language/tool , using a tool properly and efficiently is a problem.
I've only been in the industry 13 years, and I'm not using a single tool today that I used back then, but I'm still using the lessons I learned:
How much time should my team spend on testing vs. code review vs. building new features?
How risky is this feature, and how much QA does it need?
Which of the brand-new engineers on my team needs a careful eye on their code so they don't blow everything up?
When is it time to say screw it, we have to ship?
Which new hip framework is likely to have staying power, because of the people and the commitment behind it?
How do I convince open-source maintainer X to accept my new feature, so I'm not maintaining patches into eternity?
Those are the important questions I deal with every day. I couldn't answer them as well 10 years ago, and I bet I can answer them better 10 years from now.
How much time should my team spend on testing vs. code review vs. building new features?
How risky is this feature, and how much QA does it need?
Which of the brand-new engineers on my team needs a careful eye on their code so they don't blow everything up?
When is it time to say screw it, we have to ship?
Which new hip framework is likely to have staying power, because of the people and the commitment behind it?
How do I convince open-source maintainer X to accept my new feature, so I'm not maintaining patches into eternity?
Those are the important questions I deal with every day. I couldn't answer them as well 10 years ago, and I bet I can answer them better 10 years from now.
Back in 1996 I was using CVS at work. Before that it was RCS or SCCS (RCS was the first version control system I used). This was at Bell-Northern Research and Nortel, which was not a bastion of cutting edge techniques. ClearCase was pretty commonly used as well (it came out in 1992).
Automated testing wasn't science fiction. It was regularly done, just as system or integration tests. You'd see who did the commit that broke the build. This was before QA even got to do their work. This was something done across the company and I'm certain that it wasn't the only company that did this.
Automated testing wasn't science fiction. It was regularly done, just as system or integration tests. You'd see who did the commit that broke the build. This was before QA even got to do their work. This was something done across the company and I'm certain that it wasn't the only company that did this.
>So are we law and medicine or are we tomato pickers?
There's engineering and engineering. Making apps using electron.js and writing high-frequency trading software isn't the same gig. I think much of the problem described by the parent comment falls upon those programmers doing the former.
There's engineering and engineering. Making apps using electron.js and writing high-frequency trading software isn't the same gig. I think much of the problem described by the parent comment falls upon those programmers doing the former.
> If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times?
I can make ridiculous scenarios too. If the cardiac surgery is using the latest technology, which the younger surgeon had used all 4 times successfully, and the older surgeon had used once and killed the patient?
This idea that being around since COBOL = smarter/better/"we GTD while they sit around doing nothing for 16 hours" is idiotic and not at all based in reality.
I can make ridiculous scenarios too. If the cardiac surgery is using the latest technology, which the younger surgeon had used all 4 times successfully, and the older surgeon had used once and killed the patient?
This idea that being around since COBOL = smarter/better/"we GTD while they sit around doing nothing for 16 hours" is idiotic and not at all based in reality.
>If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times?
http://www.npr.org/sections/health-shots/2014/12/22/37250839...
http://www.npr.org/sections/health-shots/2014/12/22/37250839...
> If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times?
Rationally one would care about the outcomes, and the number of times would merely make us more certain about the outcome.
Relative to the two scenarios you showed, programming is usually more like tomato picking—nobody is going to die or be injured because of a bug or failure to deliver something.
Rationally one would care about the outcomes, and the number of times would merely make us more certain about the outcome.
Relative to the two scenarios you showed, programming is usually more like tomato picking—nobody is going to die or be injured because of a bug or failure to deliver something.
self driving cars.
Perhaps most of the time that's true, I suspect that a lot of health care is the same. There have been plenty of instances of software bugs killing or injuring people:
https://en.wikipedia.org/wiki/List_of_software_bugs
https://en.wikipedia.org/wiki/List_of_software_bugs
"nobody is going to die or be injured because of a bug or failure to deliver something"
You should read through RISKS Digest.[1]
[1] - https://en.wikipedia.org/wiki/Risks_digest
You should read through RISKS Digest.[1]
[1] - https://en.wikipedia.org/wiki/Risks_digest
If you were building a team to win the Super Bowl, would you pick the hot shot 23 year old fresh grad from college, or the 50 year old experienced Hall of Famer?
50 year old hall of famer? Its rare for a QB to make it to 40 years old in the NFL. Peyton Manning retired at 39 years old after he won the Super Bowl last year, and he was considered ancient and past his prime despite that achievement.
Furthermore, I just looked it up, and the oldest player to ever have played in the league was George Blanda, who retired at age 48. http://www.profootballhof.com/football-history/40-and-over-c...
Furthermore, I just looked it up, and the oldest player to ever have played in the league was George Blanda, who retired at age 48. http://www.profootballhof.com/football-history/40-and-over-c...
As a cardiologist, I would prefer to refer my patients to the cardiac surgeon who is the most skilled, regardless of their time out of training. Similarly, I don't think that a programmer's age tells me much.
Engineering might be the former. Programming and software "engineering" is definitely the latter.
I came to this realization a few years ago. I found that while my judgment was still improving, my output wasn't and my ability to think through problems wasn't where it used to be, especially when it came to the tiny details.
So I moved into management. It allowed me leverage my strengths while putting me in a situation where my value wasn't determined by my raw output. It sucks going to all those meetings, but it honestly made me enjoy the programming I did do considerably more than I did before. The programming I did do for the team was all prototype work with new technologies that either I or the team felt could help us out...short 2-3 hour projects whenever I could fit them into my schedule. But everything was new and I wasn't implementing things I'd done a ton of times before.
In the end, I don't think this is a satisfying answer. There just aren't enough managerial jobs for all the old programmers and a lot of them can't handle the meeting workload of that kind of position. But I still suggest it on an individual basis because it's a chance to put all that experience to work programming at a higher level. Instead of linked lists you're dealing with fresh-out-of-college devs who know their big-Os by heart and can crank out code at a frightening pace. But you still need someone to ensure the overall design doesn't suck. To read over what they're producing since there will always be some crazy mis-step that they make from time to time. You still need someone who has seen a project evolve over multiple years to know which decisions will become problematic down the road. The young guys can't do that. And while it's been an adjustment to learn to find satisfaction without typing out the code myself, I've learned to enjoy the launches (both product and career) in a way that's more fulfilling than my time as a full-time coder was.
So I moved into management. It allowed me leverage my strengths while putting me in a situation where my value wasn't determined by my raw output. It sucks going to all those meetings, but it honestly made me enjoy the programming I did do considerably more than I did before. The programming I did do for the team was all prototype work with new technologies that either I or the team felt could help us out...short 2-3 hour projects whenever I could fit them into my schedule. But everything was new and I wasn't implementing things I'd done a ton of times before.
In the end, I don't think this is a satisfying answer. There just aren't enough managerial jobs for all the old programmers and a lot of them can't handle the meeting workload of that kind of position. But I still suggest it on an individual basis because it's a chance to put all that experience to work programming at a higher level. Instead of linked lists you're dealing with fresh-out-of-college devs who know their big-Os by heart and can crank out code at a frightening pace. But you still need someone to ensure the overall design doesn't suck. To read over what they're producing since there will always be some crazy mis-step that they make from time to time. You still need someone who has seen a project evolve over multiple years to know which decisions will become problematic down the road. The young guys can't do that. And while it's been an adjustment to learn to find satisfaction without typing out the code myself, I've learned to enjoy the launches (both product and career) in a way that's more fulfilling than my time as a full-time coder was.
How does a programmer go about moving into management?
Ask. I had a conversation with the VP of Eng where I told him that's what I wanted, asked if it was a possibility and what I needed to do to make it happen. He told me what he thought I needed to learn and allowed me to take a couple of hours each week to read, meet with other managers and otherwise prepare. A few months later, when a position became open, he gave me a trial run which converted to perm after a successful month.
Most engineering leadership is very reasonable with requests like this provided you are a very strong performer with the respect of the engineering organization. They realize that promotions from within are morale boosters and developing a reputation for nurturing talent is an amazing recruiting tool.
Most engineering leadership is very reasonable with requests like this provided you are a very strong performer with the respect of the engineering organization. They realize that promotions from within are morale boosters and developing a reputation for nurturing talent is an amazing recruiting tool.
What's your answer for the general? Not that you know but areas you suspect.
This is one thing that really worries me. I'm in my early 30s, and I'm perfectly content working a mid-level position. I've seen people my age pass me by several times, and I'm fine with that. I'm not good enough to keep up with the really good engineers, and it's probably going to be a long time before I have 'Senior' in my title, if ever.
When I'm in my 50s, I'm just not going to be one of those awesome elder coders. My boss is one of those graybeards, and he's awesome, but I'll never be him. I also have less than zero desire to ever work in management (and even if I wanted to do that, I don't have the people skills for it). So I'm seriously worried that I'm going to be unemployable in 10-20 years because companies will all prefer to hire people in their 20s with equivalent skills to mine out of ageism.
When I'm in my 50s, I'm just not going to be one of those awesome elder coders. My boss is one of those graybeards, and he's awesome, but I'll never be him. I also have less than zero desire to ever work in management (and even if I wanted to do that, I don't have the people skills for it). So I'm seriously worried that I'm going to be unemployable in 10-20 years because companies will all prefer to hire people in their 20s with equivalent skills to mine out of ageism.
In twenty years you'll be in your 70's. Most people in their 70's are unemployable, no matter the field.
If you don't have a retirement plan, then you got to do some extreme saving and lifestyle adjustment (or you'll face even more extreme lifestyle adjustment once you retire).
If you do have a retirement plan, you have nothing to worry about.
If you don't have a retirement plan, then you got to do some extreme saving and lifestyle adjustment (or you'll face even more extreme lifestyle adjustment once you retire).
If you do have a retirement plan, you have nothing to worry about.
No, they're in their 30s. They're concerned about their 50s.
Whoops, badly misread that.
If you haven't adapted in 20 years, is it really ageism?
I think "older" programmers are more likely to stick around longer. If your looking for someone to fill space so you can brag about the hours your team is putting in and party with while you blow threw a few more of some investors millions go with the young guy. Since, the companies' going to blow up in six month anyway why worry about how long they stay in a job.
Honestly I think that might be in the back of these people's heads a bit.
"Woo! We're doing what we want, when we want, how we want, this is how work should be! What, you think it would be better if we did things this way because reasons and experience? No, this is how I always wanted to work, fast and loose, I'm the one with the CEO title so this is what we'll do!
6 months later I'm so sorry guys. I have to let you all go, then come up with another idea I can get investors to pump money into so I can hop on this ride all over again and learn absolutely nothing.
This isn't true of all startups, but I've seen elements of it at several of the ones I have experience with.
"Woo! We're doing what we want, when we want, how we want, this is how work should be! What, you think it would be better if we did things this way because reasons and experience? No, this is how I always wanted to work, fast and loose, I'm the one with the CEO title so this is what we'll do!
6 months later I'm so sorry guys. I have to let you all go, then come up with another idea I can get investors to pump money into so I can hop on this ride all over again and learn absolutely nothing.
This isn't true of all startups, but I've seen elements of it at several of the ones I have experience with.
I am with you on this - it is what causes me a lot of anxiety but what also drives me to at least know about "all the shiney things" that the new breed of engineers basically come equipped with standard.
Ignoring the Very Smart Capitalization, I haven't seen any correlation between age and {skill, productivity, intelligence, results}.
I've worked with very smart, cutting-edge literal graybeards who could code circles around me, and guys who have been at the same company in the same entry-level or mid-level programming job for 25 years yelling in a meeting about "this damn web shit."
I've worked with very smart, cutting-edge literal graybeards who could code circles around me, and guys who have been at the same company in the same entry-level or mid-level programming job for 25 years yelling in a meeting about "this damn web shit."
Right - I took the comment to be about working sane hours yields better results than working twice as long... and generally older folks are less inclined to work the 2x hours.
Even though you personally haven't observed any correlation, wouldn't you think that experienced people can make better judgement calls when designing software? Because of their experience (age), that is. Personally I feel like I'm 10x the developer I was 20 years ago. And that is 100% because of the experience and years. One learns while doing you know.
>I wouldn't worry. We can actually Get Stuff Done, which at the end of the day is what really counts.
This is a myth. It doesn't count for that much. Programmer productivity cannot be effectively measured even by other programmers and certainly can't be measured by non-technical managers.
The fact that you are doing something can be easily verified. The fact that you are doing it effectively at an appropriate speed and quality cannot.
There's a lot more trust, salesmanship, snake oil and bullshit surrounding the development of software than most of us would like to admit.
This is a myth. It doesn't count for that much. Programmer productivity cannot be effectively measured even by other programmers and certainly can't be measured by non-technical managers.
The fact that you are doing something can be easily verified. The fact that you are doing it effectively at an appropriate speed and quality cannot.
There's a lot more trust, salesmanship, snake oil and bullshit surrounding the development of software than most of us would like to admit.
> The fact that you are doing it effectively at an appropriate speed and quality cannot.
Well it can, but not in a way we necessarily like - it's called the marketplace.
Well it can, but not in a way we necessarily like - it's called the marketplace.
It's called a market for lemons.
If "it" is "producing lemons" then yes, you would need a market for lemons in order to guage the production process' quality. Well done, have a cookie. Or a lemon.
If you are correctly following an Agile process such as Scrum, the productivity of each team member can indeed be quantified. You may think it's pure bullshit numbers, but the ratio of story points to hours worked tends to stabilize over time and give management an idea of how productive you really are.
Absolute bullshit.
* A team that is being judged on scrum velocity can simply keep inflating story points to make it look like they're going faster.
* A team that is optimistic has a lower velocity. A team that is pessimistic has a higher velocity.
* If a story is 8 points that gives no clue as to whether it ought to be a 2 point (if the technical debt accrued by the team were not so high).
In practice I've found that it doesn't stabilize either. Of course that automatically means you just "weren't doing Scrum properly".
* A team that is being judged on scrum velocity can simply keep inflating story points to make it look like they're going faster.
* A team that is optimistic has a lower velocity. A team that is pessimistic has a higher velocity.
* If a story is 8 points that gives no clue as to whether it ought to be a 2 point (if the technical debt accrued by the team were not so high).
In practice I've found that it doesn't stabilize either. Of course that automatically means you just "weren't doing Scrum properly".
>If you are correctly following an Agile process such as Scrum, the productivity of each team member can indeed be quantified.
No, no, no, a thousand times no. Tracking story points by developer is the diametric opposite of "correctly following an Agile process". It gives team members, individually and collectively, an incentive to game the system, thereby corrupting your metrics and estimates. You are literally begging your team members to lie to you.
Any competent lead should be able to identify who is more and less productive without using what is essentially micromanagement by story point. Story points should only ever be tracked by team for overall velocity measurements.
No, no, no, a thousand times no. Tracking story points by developer is the diametric opposite of "correctly following an Agile process". It gives team members, individually and collectively, an incentive to game the system, thereby corrupting your metrics and estimates. You are literally begging your team members to lie to you.
Any competent lead should be able to identify who is more and less productive without using what is essentially micromanagement by story point. Story points should only ever be tracked by team for overall velocity measurements.
I've seen plenty of old developers who fancy themselves experienced who are not efficient too.
I agree more experienced people usually get stuff done and it's generally been my experience. Of course there are always exceptions. The problem I see is that often it is not the output itself that wins, rather the perception around the output.
I've seen many talentless people rise through the ranks of companies or start their own just because they were good at bs'ing, marketing themselves, had a certain personality type, and many other things that had little to do with programming directly. Of course some of these things are important and valuable, but many of them are toxic, especially in a software development context.
Indeed, we've all observed countless startups that become industry darlings that don't even ever produce real revenue let alone profits. We can argue about what their output actually is, but often it's smoke and mirrors at best, fraud at worst. This all happens often at the expense of progress or another company that actually does produce value, but fails at playing the game properly (same applies to people). But these startups "succeed" at least temporarily because they create perceptions that one day, just with many more millions and many more articles, they will be great and rule the world. Whether it catches up with them or not is something else. Perception is the way so many things in life work, and particularly important to many companies, the stock market.
I think there are just so many examples where the belief that if you work hard and do good work does not hold. I personally value these things, but many people do not. It's a complicated topic I could ramble on about forever, but I think we've all been in these situations and had things happen to use like receiving praise for arguably our worst work.
I've seen many talentless people rise through the ranks of companies or start their own just because they were good at bs'ing, marketing themselves, had a certain personality type, and many other things that had little to do with programming directly. Of course some of these things are important and valuable, but many of them are toxic, especially in a software development context.
Indeed, we've all observed countless startups that become industry darlings that don't even ever produce real revenue let alone profits. We can argue about what their output actually is, but often it's smoke and mirrors at best, fraud at worst. This all happens often at the expense of progress or another company that actually does produce value, but fails at playing the game properly (same applies to people). But these startups "succeed" at least temporarily because they create perceptions that one day, just with many more millions and many more articles, they will be great and rule the world. Whether it catches up with them or not is something else. Perception is the way so many things in life work, and particularly important to many companies, the stock market.
I think there are just so many examples where the belief that if you work hard and do good work does not hold. I personally value these things, but many people do not. It's a complicated topic I could ramble on about forever, but I think we've all been in these situations and had things happen to use like receiving praise for arguably our worst work.
> ping-pong table propaganda
Thank you for enriching my vocabulary with this wonderful word!
Thank you for enriching my vocabulary with this wonderful word!
Uh, that's a phrase, not a word...
A [decently managed] team of 5 will always outproduce you. No matter how little they work or how much better you are individually.
But 1-on-1? Experience wins evey time.
I'm not old old yet, but I do have the most experience[1] in my team. Spend the least time at work, strictly 8h/day, and am easily the top contributor by any engineering metric you can think of. Wish I could explain why or how, but the best I've been able to surmize is "I just get more done and spend less time going down wrong rabbit holes".
[1] most experience with our particular stack/domain, not necessarily most general irl software engineering experience
But 1-on-1? Experience wins evey time.
I'm not old old yet, but I do have the most experience[1] in my team. Spend the least time at work, strictly 8h/day, and am easily the top contributor by any engineering metric you can think of. Wish I could explain why or how, but the best I've been able to surmize is "I just get more done and spend less time going down wrong rabbit holes".
[1] most experience with our particular stack/domain, not necessarily most general irl software engineering experience
> A [decently managed] team of 5 will always outproduce you. No matter how little they work or how much better you are individually.
Furthermore, that team will also outproduce a 25 people team.
Furthermore, that team will also outproduce a 25 people team.
A [decently managed] team of 5 will always outproduce you.
I wouldn't be so sure. It depends on the problem you're solving. Of course for routine work it would be like that.
I wouldn't be so sure. It depends on the problem you're solving. Of course for routine work it would be like that.
And this ^^^ is what experience sounds like.
A team is certainly the right tool for some situations but often the toughest routes require a single very very good climber.
A team is certainly the right tool for some situations but often the toughest routes require a single very very good climber.
By definition most work is routine.
And yes, for phd-level (or almost) research work into new territories, one person teams are best.
And yes, for phd-level (or almost) research work into new territories, one person teams are best.
I've been into programming most of my life, but actually didn't get started professionally until my mid-to-late 20s. This gave me a unique view of said propaganda. It certainly lives everywhere including outside SV. I've been able to quickly recognize it being applied and thus desire other, better forms of compensation.
I think this is a skill we should strive to teach younger programmers, because if properly applied across the entire industry, we can raise standards across the market.
Just because they're willing to working 1.5-2X the hours doesn't mean they should be. Your time is valuable no matter how old you are
I think this is a skill we should strive to teach younger programmers, because if properly applied across the entire industry, we can raise standards across the market.
Just because they're willing to working 1.5-2X the hours doesn't mean they should be. Your time is valuable no matter how old you are
Yeah definitely. I actually work in academia (I guess I wasn't very qualified to speak about SV). But it's the same shtick everywhere. Passion has become an euphemism for soft corporate brain-washing.
I am reminded of this blog article by an ad executive before his death where he raised similar points about his industry:
http://www.lindsredding.com/2012/03/11/a-overdue-lesson-in-p...
I am reminded of this blog article by an ad executive before his death where he raised similar points about his industry:
http://www.lindsredding.com/2012/03/11/a-overdue-lesson-in-p...
>(You don’t have to drive creative folk like most workers. They drive themselves. Just wind ’em up and let ’em go.)
Great link: Very, VERY insightful.
Great link: Very, VERY insightful.
Agreed. What an excellent read! Highly recommended.
I always like to think of passion in the classical meaning (like "the passion of Christ") when I read crap about being passionate at work.
> Your time is valuable no matter how old you are
I disagree, but maybe that would explain it, your time is actually more valuable (for you) as you grow older.
I disagree, but maybe that would explain it, your time is actually more valuable (for you) as you grow older.
The time between 20-35 is the most valuable time in your life imho. You will regret wasting this time for some death marches for a startup which promise you a lot of bullshit.
Of course you will regret it! Because, as I said, your time becomes more valuable as you get older. You're confusing good advice and empirical observation of reality.
Anyway, let me add to my previous comment. It cuts both ways. If someone hires somebody who doesn't think their time is valuable, they are fooling themselves too. Perhaps this person will spend 2 hours on ping-pong and 2 hours on Facebook out of their 12 hour shifts, because they do not value their time as much yet.
Anyway, let me add to my previous comment. It cuts both ways. If someone hires somebody who doesn't think their time is valuable, they are fooling themselves too. Perhaps this person will spend 2 hours on ping-pong and 2 hours on Facebook out of their 12 hour shifts, because they do not value their time as much yet.
[deleted]
To share me / and things that keep me up at night:
I am an old geek - (34 now - i guess)... I still need to work the 12 hour days in order to keep up with my day job AND to keep up with new technologies and the literature via Pluralsight, Github / HN / Coursera etc.
This is what I really worry about in terms of my health and longevity: Being able to "stay on top" of the latest trends and shiney new things - and deciding what will matter in 3 years, and what is just another "fad".
I am an old geek - (34 now - i guess)... I still need to work the 12 hour days in order to keep up with my day job AND to keep up with new technologies and the literature via Pluralsight, Github / HN / Coursera etc.
This is what I really worry about in terms of my health and longevity: Being able to "stay on top" of the latest trends and shiney new things - and deciding what will matter in 3 years, and what is just another "fad".
This is why, at age 38, I deliberately chose to move to big-tech-company-x. As it turns out, most of my colleagues are older than me and starting to look towards their pensions.
The tech is 10 years out of date, but it's so ingrained in the customer sites that it's going to stay there. There are plenty of jobs like this out there in finance, public institutions (or big companies serving them), the military (military projects can go on for decades) and so on. I get job security and a decent pension building up, they get an experienced developer in return.
And in the meantime I can choose to look at shiny-new-thing without having to worry my career might depend on it.
People might think 38 is a bit early to "sell out", but our industry is definitely ageist. It's not easy for non-techs to see the difference between an experienced dev who wants £100k that knows technology x and a graduate who wants £fuck-all and knows technology x.
The tech is 10 years out of date, but it's so ingrained in the customer sites that it's going to stay there. There are plenty of jobs like this out there in finance, public institutions (or big companies serving them), the military (military projects can go on for decades) and so on. I get job security and a decent pension building up, they get an experienced developer in return.
And in the meantime I can choose to look at shiny-new-thing without having to worry my career might depend on it.
People might think 38 is a bit early to "sell out", but our industry is definitely ageist. It's not easy for non-techs to see the difference between an experienced dev who wants £100k that knows technology x and a graduate who wants £fuck-all and knows technology x.
Until that one consultant moves in, and convinces someone higher up that you need to move to microservices and containerize all the things, and next thing you know, you are all growing mustaches, wearing suspenders and horn-rimmed glasses, taking Lyft's to work, and clamoring for the company to sponsor your Chemex habits.
And then the consultants leave, and the experienced developers have to fix the crummy bug-ridden code they leave behind. :)
As an older developer, I think one advantage I do actually have is that I do know legacy technology. You don't want to become a developer that only knows that, but as long as I reasonably keep up with current technology and don't become a Grumpy Old Back In My Day type of old developer, that should add, not subtract. At my current job, there are actually some VB6 apps still in operation, so sometimes I am actually pulling up VB6 apps to fix or enhance to go along with the shiny new Angular 2 apps we're working on.
Yes I know that I don't have the energy to pursue the move-fast-break-things life of startup style companies, but not every company is like that.
As an older developer, I think one advantage I do actually have is that I do know legacy technology. You don't want to become a developer that only knows that, but as long as I reasonably keep up with current technology and don't become a Grumpy Old Back In My Day type of old developer, that should add, not subtract. At my current job, there are actually some VB6 apps still in operation, so sometimes I am actually pulling up VB6 apps to fix or enhance to go along with the shiny new Angular 2 apps we're working on.
Yes I know that I don't have the energy to pursue the move-fast-break-things life of startup style companies, but not every company is like that.
So you spend 8h working and 6h reading and learning? I'm an advocate for just-in-time learning. Read HN to get a high level overview of the cool shit. Then wait to learn the details until you actually need to use it.
There's always something new and cool to learn. It's pointless if you never use that knowledge.
There's always something new and cool to learn. It's pointless if you never use that knowledge.
The valley pays a lot so if you want to get in that club you have to play that game.The investors don't care about your family. They are interested in making money to feed their family. They found a formula and I don't think they are going to change it. Look at the Big 4: MSFT, APPL, AMNZ, FB. All their founders were on the right side of 30 except maybe bezos.
It is kind of troubling the age that you are getting old seems to keep getting lower. Now 30 is old. In the future it might be 27. Node was only made like 6-7 years ago and it seems to be one of the most popular "Languages" out there.
Based on my experience well thought out designs are not so admired even though people say it is. It seems like the "mantra" is just get something out of the door and we will iterate on it.
It is kind of troubling the age that you are getting old seems to keep getting lower. Now 30 is old. In the future it might be 27. Node was only made like 6-7 years ago and it seems to be one of the most popular "Languages" out there.
Based on my experience well thought out designs are not so admired even though people say it is. It seems like the "mantra" is just get something out of the door and we will iterate on it.
I have to agree. I'm getting up there too. I'm the second oldest person at my current startup and I looked around yesterday and realized that I wasn't that much more valuable than the 23-26 year olds I work with. I think I'm a damn site more technical than they are, and I also think I manage my time better than they do, but I don't think I provide that much more value to the organization. Especially given the lengths to which they will go to burn through work (i.e. long hours and weekend work).
I personally think that 95% of organizations out there only need/want what the 23 year olds can provide.
I'm holding out hope though that when it comes to truly valuable and technically challenging work that more mid-level to large-ish companies still have teams that value the stability and vision more mature developers can offer. I think this is my last startup for a while.
I think this article hit the nail on the head. It takes a very mature and self-assured person to hire someone more qualified than they are and then hand over the commensurate freedom and responsibility along with it.
I personally think that 95% of organizations out there only need/want what the 23 year olds can provide.
I'm holding out hope though that when it comes to truly valuable and technically challenging work that more mid-level to large-ish companies still have teams that value the stability and vision more mature developers can offer. I think this is my last startup for a while.
I think this article hit the nail on the head. It takes a very mature and self-assured person to hire someone more qualified than they are and then hand over the commensurate freedom and responsibility along with it.
My experience is that younger developers take on way too much risk. It's either because they don't know how to manage risk, or they just get a rush from it. Unfortunately, there's a lot of survivorship bias that makes it seem that that is the way to go.
Back in the day, it was well known that spending more time in the inception and elaboration phases would make construction much more cost effective. It was also known that developer efficiency decreased significantly after a certain threshold of hours worked. Maybe things have changed - I don't know. It sure feels like well analyzed requirements and well designed architectures yield much better products. And, more experienced developers _should be_ better at those things, on average.
I wish there was more data data on the subject - I need to start reading more research coming out of the ACM SIG.
Back in the day, it was well known that spending more time in the inception and elaboration phases would make construction much more cost effective. It was also known that developer efficiency decreased significantly after a certain threshold of hours worked. Maybe things have changed - I don't know. It sure feels like well analyzed requirements and well designed architectures yield much better products. And, more experienced developers _should be_ better at those things, on average.
I wish there was more data data on the subject - I need to start reading more research coming out of the ACM SIG.
For me, what works is "productivity sniping": it's not about work rate, however you might want to quantify it, but about occasionally encountering problems that others find intractable and making them go away. In this case having a set of old experiences actually helps, as I can handle things that new graduates haven't seen.
I half-seriously call it "full stack from the transistor up".
I half-seriously call it "full stack from the transistor up".
Most startups do not work 12 hour days anymore. The days of startups offering less pay, some equity and overworking you are over. There are too many startups that need engineers. They would just move on to the next one. Retaining good engineers is harder than hiring them. I've worked 12 hours when I was a founder but it's unrealistic to expect that from your employees regardless their age.
The jading goes much deeper than 12 hour days and "culture", in my opinion.
It's "easy" to get stuff done if you have no strong feeling of responsibility for the longevity of the things you're working on, or if you've never experienced the pain that comes with this lack of planning/implementation. The first 90% is easy, but the last 10% is what makes things stable, performant, maintainable, deployable and secure (not advocating for doing this last; just saying it's easy to ignore).
It's also easy to be excited about things when you['re naïve enough to] expect them to work "properly". People who've been doing this for a long time recognize that it's really rare that software Just Works™, and for that reason, things need to be architected to make room for failure. Building things without an acceptable failure mode is super fun until it fails, and then it's even worse than not doing it in the first place.
Doing stuff right takes a long time and is hard. It's truly satisfying to nail it, but it's certainly not always fun/exciting.
It's "easy" to get stuff done if you have no strong feeling of responsibility for the longevity of the things you're working on, or if you've never experienced the pain that comes with this lack of planning/implementation. The first 90% is easy, but the last 10% is what makes things stable, performant, maintainable, deployable and secure (not advocating for doing this last; just saying it's easy to ignore).
It's also easy to be excited about things when you['re naïve enough to] expect them to work "properly". People who've been doing this for a long time recognize that it's really rare that software Just Works™, and for that reason, things need to be architected to make room for failure. Building things without an acceptable failure mode is super fun until it fails, and then it's even worse than not doing it in the first place.
Doing stuff right takes a long time and is hard. It's truly satisfying to nail it, but it's certainly not always fun/exciting.
10x is greater than 2x, so yes it is possible
The fact that 40yo is considered "old" in this industry is why we have such shallow culture and so much cargo cult and rediscovery of stale (or even discarded) techniques as the latest BS fad.
Consider a law firm or hospital with no professionals over 40...
It fits with SV, because it just needs code monkeys to build what's basically simple apps in whatever language du jour. Things that are touted as big solutions in web-land for example, have been done, tried and are commonplace in all other parts of IT.
Places and firms that build important stuff, where Computer Science matters (embedded code, OSes, databases, critical systems, etc) do hire "older" people, and some even mostly older people.
Consider a law firm or hospital with no professionals over 40...
It fits with SV, because it just needs code monkeys to build what's basically simple apps in whatever language du jour. Things that are touted as big solutions in web-land for example, have been done, tried and are commonplace in all other parts of IT.
Places and firms that build important stuff, where Computer Science matters (embedded code, OSes, databases, critical systems, etc) do hire "older" people, and some even mostly older people.
E.g. - "No-SQL" reeks of the "Codasyl" model from the 60s, which relational databases replaced for good reason, whether or not Structured Query Language is the only way to interact with the tuples/tables.
https://en.wikipedia.org/wiki/CODASYL
Ad nauseam...
https://en.wikipedia.org/wiki/CODASYL
Ad nauseam...
Exactly, NoSQLs are nothing new -- they are the tried and failed old, that got replaced by RDBMS for good reasons (unless you also have a good reason, e.g. you run at Google's scale).
People do "data science" and don't even know the various canonical forms (which are mathematical notions that apply to all kinds of data models, not just SQL DBs).
People do "data science" and don't even know the various canonical forms (which are mathematical notions that apply to all kinds of data models, not just SQL DBs).
Then there's a "nuance" aspect you could use: maybe we do want a hierarchical model -- in a "middleware" level, for a specific app, just not for the operational data store used by multiple applications.
But your "yellow belt" coder might not do this, or, might build out a bunch of layers for something trivial, because that is what was in The Book.
Amen! (preaching to the choir, at this point, sorry)
But your "yellow belt" coder might not do this, or, might build out a bunch of layers for something trivial, because that is what was in The Book.
Amen! (preaching to the choir, at this point, sorry)
I actually love this.
I've never worked in the valley, and honestly I feel no pressing urge to based on what I hear with regards to the bias in favour of twenty-somethings who can work 15+ hour days and live off of ramen.
I'm pushing into my mid-thirties this year, I'm married with two young children, and I simply can't work the kind of hours that I could ten years ago.
The thing is, I didn't do it then either, even when I could. I've always had the mentality that if I'm going to commit to your project, you're going to compensate me in cash or equity. It may also be why I'm happier in my career now that I contract than I ever was before. A days (genuinely hard) work for a days pay.
I simply never understood why someone would give so much of themselves for free in the pursuit of someone else's goals without a substantial slice of the pie. I still don't. And I suspect this is in large part why older developers are looked over (although maybe there's more to it).
Good job on the site, it certainly looks like its getting a lot of traction!
I've never worked in the valley, and honestly I feel no pressing urge to based on what I hear with regards to the bias in favour of twenty-somethings who can work 15+ hour days and live off of ramen.
I'm pushing into my mid-thirties this year, I'm married with two young children, and I simply can't work the kind of hours that I could ten years ago.
The thing is, I didn't do it then either, even when I could. I've always had the mentality that if I'm going to commit to your project, you're going to compensate me in cash or equity. It may also be why I'm happier in my career now that I contract than I ever was before. A days (genuinely hard) work for a days pay.
I simply never understood why someone would give so much of themselves for free in the pursuit of someone else's goals without a substantial slice of the pie. I still don't. And I suspect this is in large part why older developers are looked over (although maybe there's more to it).
Good job on the site, it certainly looks like its getting a lot of traction!
I simply can't work the kind of hours that I could ten years ago.
I find this is true in two ways; not only do I have better things to do now than donate free overtime to my employer, I am far better at not needing to. My best work in recent memory involved reading and thinking and sketching for a day and a half, and then adding six characters and a space to the front of one line of code; a decade ago, there is a real chance I would have ploughed into the problem with rewrites and architecture changes and all sorts of bad ideas.
This does not solve the perennial problem that a less-skilled programmer thrashing away for days appears to be doing a lot more for the company than someone who sits unmoving for a morning and then strokes the code with a feather.
I find this is true in two ways; not only do I have better things to do now than donate free overtime to my employer, I am far better at not needing to. My best work in recent memory involved reading and thinking and sketching for a day and a half, and then adding six characters and a space to the front of one line of code; a decade ago, there is a real chance I would have ploughed into the problem with rewrites and architecture changes and all sorts of bad ideas.
This does not solve the perennial problem that a less-skilled programmer thrashing away for days appears to be doing a lot more for the company than someone who sits unmoving for a morning and then strokes the code with a feather.
What were the six characters?
Reminds me of the old joke/parable about the mechanic charging $1 for turning a screw and $499 for knowing which screw to turn.
Reminds me of the old joke/parable about the mechanic charging $1 for turning a screw and $499 for knowing which screw to turn.
> I simply never understood why someone would give so much of themselves for free in the pursuit of someone else's goals without a substantial slice of the pie.
They believe what they are told - that hard work will be rewarded by salary increases, ability to work on interesting stuff and much respect.
They believe what they are told - that hard work will be rewarded by salary increases, ability to work on interesting stuff and much respect.
I must admit there was a time I believed that nonsense myself, so I shouldn't really judge!
Ugh. This is so me. I turned 40 last year. Did CS, writing code is still the fun part of the job. Anyway, I used to maintain a fashionable amount of stubble. This year I noticed my beard was starting to go grey. Now I shave a lot more to hide it. This is the first time in my professional life I have started worrying about being judged on how I look. I also need to change the way I dress. I am too old to keep doing the tshirt, jeans and running shoes thing. I think I will go with: polo shirt, jean and leather shoes. Ha! Those damn whippersnappers won't spot me!
try searching for: "kids in the hall He's Hip. He's Cool. He's 45!"
If the story about Gosling is even 10% accurate, that is shocking.
try searching for: "kids in the hall He's Hip. He's Cool. He's 45!"
If the story about Gosling is even 10% accurate, that is shocking.
My one comment would be: GET OUT OF THE VALLEY. People have far less resistance to hiring people of various ages outside of Silicon Valley.
[deleted]
I don't work anywhere near silicon valley but I am in a very small (<10 people) dev shop on the east coast and my experience has actually been exactly opposite. Out of the 4 developers I am currently the youngest at 32 (we had a 23 y/o at one point though for a period of time). The IT/dev industry here seems to be older on average with lots of devs in the 40-50 range.
I have noticed some minor ageism towards younger developers but it tends to be more jovial teasing and joking about how lucky younger devs are to have the tech ecosystems that we do as opposed to 10-20 years ago. Most of the ageism I see is related to popular culture (music, movies, etc) which can still be somewhat toxic when any age group assumes that only the media from their generation was good and everything else is crap. I have noticed more bias against devs without formal education (which everyone else has with either bachelors or masters in CS) but if a well self-taught dev without a degree came in I don't think it would be an issue.
For the most part though the "older" (its hard to think of people in their early-mid 40's as old right now) devs have a wealth of experience from whom I parasitically absorb as much as I can. It doesn't hurt that they are as competent in new tech stacks as most younger devs (even if they are more conservative about when to adopt new tools, giving them time to mature). The culture here is that someone has to make a really good case for why we should pull a ton of overtime, more often than not someone made promises they shouldn't have and its not our job to deliver on timeframes we were not consulted on. What OT work I have done I have been compensated extra for but it is partly the influence of the older devs that makes me feel like I should expect compensation when I go above and beyond. Thats not to say I'm not willing to do it to help the company (which helps us all), but I think I was able to pass the naive stage a lot quicker and I could have been taken advantage of much more in a bigger company without our developer culture.
I have noticed some minor ageism towards younger developers but it tends to be more jovial teasing and joking about how lucky younger devs are to have the tech ecosystems that we do as opposed to 10-20 years ago. Most of the ageism I see is related to popular culture (music, movies, etc) which can still be somewhat toxic when any age group assumes that only the media from their generation was good and everything else is crap. I have noticed more bias against devs without formal education (which everyone else has with either bachelors or masters in CS) but if a well self-taught dev without a degree came in I don't think it would be an issue.
For the most part though the "older" (its hard to think of people in their early-mid 40's as old right now) devs have a wealth of experience from whom I parasitically absorb as much as I can. It doesn't hurt that they are as competent in new tech stacks as most younger devs (even if they are more conservative about when to adopt new tools, giving them time to mature). The culture here is that someone has to make a really good case for why we should pull a ton of overtime, more often than not someone made promises they shouldn't have and its not our job to deliver on timeframes we were not consulted on. What OT work I have done I have been compensated extra for but it is partly the influence of the older devs that makes me feel like I should expect compensation when I go above and beyond. Thats not to say I'm not willing to do it to help the company (which helps us all), but I think I was able to pass the naive stage a lot quicker and I could have been taken advantage of much more in a bigger company without our developer culture.
When a 37 year old has to say he's "old," there's something terribly wrong with our industry.
How is any industry supposed to build a repository of expertise and wisdom if we're telling people they're washed up before they're even old enough to have their student loans paid off?
How is any industry supposed to build a repository of expertise and wisdom if we're telling people they're washed up before they're even old enough to have their student loans paid off?
Ageism is definitely a thing but its also an interesting strategic advantage. Historically the company with the best mix of experience and energy have been the ones that succeed in the long run. That said, for the first 2 - 5 years of their life a company is pretty much a random series of experiences teaching the employees what they don't know. They have to get to the point where they can actually see that there is a lot to learn and not enough time to learn it before they can value someone who has that experience.
Old engineers are like security enhancements, they seem to cost more than they are worth until you experience an event that would have killed your company if they hadn't been there.
Old engineers are like security enhancements, they seem to cost more than they are worth until you experience an event that would have killed your company if they hadn't been there.
I have achieved some consolation for pouring years of my life into technologies which I should have known would become obsolete by spending the last few years studying classical languages (mostly Attic Greek), the knowledge of which will never be obsolete. I believe there is also some value in studying the classics of Computer Science as well (Turing, Shannon, McCarthy, Graham, Dijkstra, etc.), and doing CS archeology (building retro computers from old parts, etc.).
This knowledge won't help me get a job as a coder at an SV startup, but it does help me to understand why I shouldn't try to get it, and to ease the discomfort of a fate of relative poverty.
This knowledge won't help me get a job as a coder at an SV startup, but it does help me to understand why I shouldn't try to get it, and to ease the discomfort of a fate of relative poverty.
Any jobs? I know:
Format c: /s
FWA BSS 0
\027&l10
And I have my own laplink (with cables!) and will let you borrow my Compaq portable laptop.
Format c: /s
FWA BSS 0
\027&l10
And I have my own laplink (with cables!) and will let you borrow my Compaq portable laptop.
Yeah? I know how to invoke IEFBR14 and could probably reimplement it from scratch.
I think it takes all kinds to make a good team. Young, old, men, women, and everyone across the spectrum. As an older geek now it's easy to look back at how naïve and energetic I was in my youth... but I did a lot of good work then too. I'm not much slower now but I'm much more calculating and tactical.
I work on a team with an unbalanced mix of age... but working with my younger colleagues is always a pleasure. We help each other back and forth with various aspects of the problem.
I work on a team with an unbalanced mix of age... but working with my younger colleagues is always a pleasure. We help each other back and forth with various aspects of the problem.
Blog - "Post your jobs free"
Actual website - "Post a job for $50"
Actual website - "Post a job for $50"
37 (!)
ironically, 37 was the last age at which i felt "young", for some vague psychological reason 38 was the year that tipped me into "sliding towards middle age".
ironically, 37 was the last age at which i felt "young", for some vague psychological reason 38 was the year that tipped me into "sliding towards middle age".
Same here (now 39). Also same initials but with an "s" in the middle :-)
As long as you're interested in software development and that's why you get up in the morning, it doesn't matter how old you are.
Goodluck with your YC application
I would absolutely _love_ to have some more experienced people on my team.
When I was a 20-something I'd scratch my head at having hired guys that had never heard of version control, and didn't think in OO terms. I turned my nose up to procedural programming they wrote with ease.
I wrote them off at the time out of tech-bias-myopia that is intrinsically age-based. Question is, what will I be written off for that I can then blame on age? What if I disagree with the new trend?
"These young whipper-snappers with their javascripts on the servers! Fools, the whole lot!"
I wrote them off at the time out of tech-bias-myopia that is intrinsically age-based. Question is, what will I be written off for that I can then blame on age? What if I disagree with the new trend?
"These young whipper-snappers with their javascripts on the servers! Fools, the whole lot!"
Interesting idea whose time perhaps has come. As a 38 year old developer who frequents HN and sees age related posts every once in a while, I am worried about my prospects after turning 40... Although I have no other reason to believe that I've been discriminated against over my age so far. Maybe this is a more of a Valley syndrome, or a US syndrome. In anycase, the fact that our industry itself can be thought of being around 40-50 years old now, something like this is perhaps a good thing.
I love it. Good luck!
I got invited to a YC event - meet companies, they pitched - a recruiting event. More than a few pulled the "we work hard, play hard, are a family" card.
If you have friends/family, avoid such.
Cultural fit is bull shit. It's about getting people to work more at a fixed rate. I've been there, done that, ran away to better things.
As someone expected to write code - make sure "operations" isn't a hidden requirement - devops - could meaning call duty. If you were not required to be operational when hired, and suddenly fall into the roll, start looking around. Operations takes planning, but some use "culture" as an excuse for lack of planning.
If you have friends/family, avoid such.
Cultural fit is bull shit. It's about getting people to work more at a fixed rate. I've been there, done that, ran away to better things.
As someone expected to write code - make sure "operations" isn't a hidden requirement - devops - could meaning call duty. If you were not required to be operational when hired, and suddenly fall into the roll, start looking around. Operations takes planning, but some use "culture" as an excuse for lack of planning.
Claiming "we are a family" in a business environment is always a reg flag for me. Team is a much better metaphor. Sports teams back each other up, but ultimately underperformers get dropped. You don't get fired from a family, you don't stop being a brother, sister, father or mother.
This. The most tight knit people I've met are in military special operations: Nothing comes close to the combination of technical skills, teamwork and ability to mitigate "interpersonal friction" that those guys have, IMO.
The telling thing is: Not once have I heard these folks refer to themselves as a "family" - almost like it is an insult to what family really is (separate and sacred). Only have I heard them refer to themselves collectively as a "team" or a "community".
The telling thing is: Not once have I heard these folks refer to themselves as a "family" - almost like it is an insult to what family really is (separate and sacred). Only have I heard them refer to themselves collectively as a "team" or a "community".
> military special operations: Nothing comes close to the [...] ability to mitigate "interpersonal friction" that those guys have, IMO.
Any training material, courses or books on this? I need to improve my handling of "interpersonal friction".
Any training material, courses or books on this? I need to improve my handling of "interpersonal friction".
Check out any books / articles relating to the Marine Corps' "The Basic School" - It is where newly commissioned officers (and warrant officers) learn how to lead Marines.
My fav is: "One Bullet Away: The Making of a Marine Officer" - by Nate Fick.
Long story short - The Basic School and training cadre are so effective at producing outstanding leaders, that MBA programs like Harvard and Wharton have built in a number of aspects of it to their "team building" courses / sequences: http://news.smeal.psu.edu/news-archive/2014/united-states-ma...
My fav is: "One Bullet Away: The Making of a Marine Officer" - by Nate Fick.
Long story short - The Basic School and training cadre are so effective at producing outstanding leaders, that MBA programs like Harvard and Wharton have built in a number of aspects of it to their "team building" courses / sequences: http://news.smeal.psu.edu/news-archive/2014/united-states-ma...
MCDP-1
My view on this is that the people I work with are colleagues and not family. I don't consider coworkers friends. I'm friendly with them, but not friends. We're at work to mutually put money in each other's pockets, not to form deep personal bonds. This view takes some finesse to develop; it's a fine line to walk, but I've found it works for me
Thanks for the great analogy. My employer had layoffs recently but has always referred to employees as family. always thought that was a terrible analogy as you said because you don't fire your mom or dad.
It seems to me that, as others have suggested, this might be just a silicon valley bias, real or perceived.
At 32, my skills in both hard and soft outstrip anything a developer in their early twenties could match, no matter how passionate or innately skilled they are. There is a certain 'momentum' you pick up as you get older, especially if you have been constantly feeding it with new experiences, learnings and failures. Having confidence and the skill to back it up can only be obtained with a decade or two in the industry.
And if my contracting rates and employment prospects are anything to go by, employers recognise that.
At 32, my skills in both hard and soft outstrip anything a developer in their early twenties could match, no matter how passionate or innately skilled they are. There is a certain 'momentum' you pick up as you get older, especially if you have been constantly feeding it with new experiences, learnings and failures. Having confidence and the skill to back it up can only be obtained with a decade or two in the industry.
And if my contracting rates and employment prospects are anything to go by, employers recognise that.
I would say that in my late 30's I was hitting my peak in terms of raw ability and experience. At least as far as ability is concerned, I really didn't hit a downturn until much later. Now, getting on to 50, I'm noticing that my ability to deal with complexity is quite a bit diminished. But my tolerance for complexity is likewise diminished. When I would have accepted a poorly factored solution, now I scratch my head until I find a way that allows me to understand it.
When you get down to it, do you really want to tailor your code base to the top 1% of coders? How will you sustain that practice? By paying people 4 times as much? Even then you aren't going to nab all the amazing people. Hire some people who know how to dumb down your code base. It pays dividends.
When you get down to it, do you really want to tailor your code base to the top 1% of coders? How will you sustain that practice? By paying people 4 times as much? Even then you aren't going to nab all the amazing people. Hire some people who know how to dumb down your code base. It pays dividends.
>When you get down to it, do you really want to tailor your code base to the top 1% of coders?
I think I agree with your sentiment, but to me a "top 1% coder" is someone who knows how to make things simple and readable, and knows the best abstraction to use for the goal. It's not the person who can write and/or follow the most complicated code. To me complicated code is generally a sign of a poor coder. There are exceptions, but they're rare.
I think I agree with your sentiment, but to me a "top 1% coder" is someone who knows how to make things simple and readable, and knows the best abstraction to use for the goal. It's not the person who can write and/or follow the most complicated code. To me complicated code is generally a sign of a poor coder. There are exceptions, but they're rare.
Yup. The "we only hire the best" thought process is delusional and irrational.
I will be 63 in a few days. If 37+ makes you an old geek I must be ancient. At least I am employed.
If you remember fixing a Y2K bug, you must be an old geek.
There are plenty of people who worked on Y2K bugs who are not even old enough to be a US President.
I mean that sounds neat but the math doesn't match up.
You have to be 35 to be President, so being generous let's take a 35 year old now, so they were born in 1982 give or take (2017-35).
They would have had to get a programming job right out of HS and even then best case it would have been halfway through 1999. More accurately, they likely didn't enter the workforce until 2004 or 2005.
You have to be 35 to be President, so being generous let's take a 35 year old now, so they were born in 1982 give or take (2017-35).
They would have had to get a programming job right out of HS and even then best case it would have been halfway through 1999. More accurately, they likely didn't enter the workforce until 2004 or 2005.
Or they'd have to have been programming as college students. This wasn't uncommon when I was in school.
> I’ve published a dozen articles ... build software with thousands of paying customers. ... work on open source Python. ... read almost 40 business books, and I live and breathe HackerNews.
Why not start your own business or become CTO? Why work for someone less experienced?
Why not start your own business or become CTO? Why work for someone less experienced?
Starting your own business always entails some risk. Some people are not comfortable taking that risk, surely if you have a family to support it might not be feasible. This depends a bit on the country where you live, but where I live you are liable for your company - which means that what you own privately is shared.
I don't know how it's like where he lives, but the risk might not be worth it. It also takes a huge amount of dedication and work to make it work, I can imagine that at his age, his priority would lie with his family. (Hell, I'm a decade younger and my priority lies there, wife + kids should be a priority).
Of course, the CTO option seems good in that case :-)
I don't know how it's like where he lives, but the risk might not be worth it. It also takes a huge amount of dedication and work to make it work, I can imagine that at his age, his priority would lie with his family. (Hell, I'm a decade younger and my priority lies there, wife + kids should be a priority).
Of course, the CTO option seems good in that case :-)
> Of course, the CTO option seems good in that case :-)
CTO typically means lots of travelling, which isn't really good if you're prioritizing your family (well, unless you can bring your family with you, and you probably can't).
At half the companies, the CTO is the head of all engineering, and at the other half, the CTO is responsible for evangelizing the technology. In both cases, but especially the latter, you are going to be the public face of the technical side of the company. Expect lots of travelling to conferences and other speaking engagements, and expect the sales team to call you in on sales trips to help sell the product to high-rolling customers. If your company has multiple offices around the world, you're also going to be expected to tour the offices as well.
All this time travelling is time you won't be spending with your family.
CTO typically means lots of travelling, which isn't really good if you're prioritizing your family (well, unless you can bring your family with you, and you probably can't).
At half the companies, the CTO is the head of all engineering, and at the other half, the CTO is responsible for evangelizing the technology. In both cases, but especially the latter, you are going to be the public face of the technical side of the company. Expect lots of travelling to conferences and other speaking engagements, and expect the sales team to call you in on sales trips to help sell the product to high-rolling customers. If your company has multiple offices around the world, you're also going to be expected to tour the offices as well.
All this time travelling is time you won't be spending with your family.
Consulting business is pretty low risk.
I started my own business when my wife was pregnant. I found it much more family friendly than 9-5 cubicle job.
I started my own business when my wife was pregnant. I found it much more family friendly than 9-5 cubicle job.
True that seems to be low-risk, and 9-5 cubicle might not be family friendly either. But I'm working for a company where I can choose my own hours to a certain degree (in between 8-12, leave after 8 hours with one hour break). So I can be home rather early.
Plus work from home means that I can easily take care of making dinner etc.
But I didn't consider a consulting business and actually I have no idea how your day looks like in that area. Care to elaborate, I'd love to hear about it :-)
Plus work from home means that I can easily take care of making dinner etc.
But I didn't consider a consulting business and actually I have no idea how your day looks like in that area. Care to elaborate, I'd love to hear about it :-)
Location independence, 60% time without work...
[deleted]
Not as easy as it sounds. I am 49, and been programming for over 30 years now. I've just written a few SaaS apps and trying to get them to a level where they can earn me enough money for my wife and I to semi retire and work from anywhere.
However, getting VCs and other investors to take an interest is proving very difficult. As soon as I say that I am (a) a single founder and (b) just shy of my 50th birthday, I never hear back from them. It seems that 3 decades of experience and running my own software development & consulting company writing apps for small business just isn't as cool as a group of young twenty somethings coming up with an esoteric idea out of left field that may or may not be profitable?!?
However, getting VCs and other investors to take an interest is proving very difficult. As soon as I say that I am (a) a single founder and (b) just shy of my 50th birthday, I never hear back from them. It seems that 3 decades of experience and running my own software development & consulting company writing apps for small business just isn't as cool as a group of young twenty somethings coming up with an esoteric idea out of left field that may or may not be profitable?!?
I don't think you deserve the downvotes, it seemed like a genuine question.
Becoming CTO (or in general, moving into management) is not for everyone. That said, in practical terms it behooves the early/mid thirties developer to have some kind of plan to mitigate age discrimination. Consulting is a good half way point.
Becoming CTO (or in general, moving into management) is not for everyone. That said, in practical terms it behooves the early/mid thirties developer to have some kind of plan to mitigate age discrimination. Consulting is a good half way point.
> two early twenty year olds.... Even though their job advertisement called for the passionate, opinionated, and entrepreneurial-type, they really wanted someone who could become that under them. Both were solid, but according to LinkedIn, neither had much experience outside college.
I just dont understand why someone with so much experience would apply for entry level position, under some college greenhorns.
I just dont understand why someone with so much experience would apply for entry level position, under some college greenhorns.
Not everyone want's to be a CTO, I'm thinking about that but I would prefer to be a programmer. I'm only 32.
32 too. Recently I suddenly got CTO-like responsibilities and at first glance it was not what I wanted to do. There was fear whether employees will understand and do it right way. Otoh, I think it is what we actually should do -- merge our experience and vision into the team at high level, because it allows to build something bigger and greater than just yourself. As I read recently in some book, good leader doesn't control things, but provides correct context of thinking, allows others to participate in their way to the common goal. I missed these context constraints when I was young, so many efforts simply lost in unnecessary details.
Because not everyone has the skillset or temperament to be a CTO, nor an interest in the work involved?
Because not everyone can stomach the risk involved in entrepreneurship?
Because not everyone can stomach the risk involved in entrepreneurship?
Risk, amount of work hours?
If Jaromir Jagr, at 44 years of age, can play at the highest level of professional hockey in the world, leading his young team in points (and 2nd in goals) last season [1] just imagine what a programmer can do with the same level of focus and determination at that age and beyond.
[1] https://www.nhl.com/panthers/stats/regular-season/skaters/p
[1] https://www.nhl.com/panthers/stats/regular-season/skaters/p
Chris Terril completed Royal Marine Commando training at 55!
https://en.wikipedia.org/wiki/Chris_Terrill
https://www.youtube.com/watch?v=XmlHxIqVoxE
NB He did this so that he would feel fit enough to accompany them as a reporter to Afghanistan - I think the normal upper age limit is 27.
https://en.wikipedia.org/wiki/Chris_Terrill
https://www.youtube.com/watch?v=XmlHxIqVoxE
NB He did this so that he would feel fit enough to accompany them as a reporter to Afghanistan - I think the normal upper age limit is 27.
Cliff Young won an Ultra Marathon at 61!
https://en.wikipedia.org/wiki/Cliff_Young_(athlete)
Isn't the main argument against employing older developers that they won't have that level of focus and determination? Pointing to an statistical anomaly and suggesting that older people can be that focused is easily countered with an argument that, while that's true, it's far more likely that a younger person will have the traits you're looking for, so you should employ them instead.
A rare example of a hyper-focused older person[1] isn't a reason to hire older people. Hiring is about filling a position with someone capable of doing what's necessary. It's not about finding someone exceptional. You want to get someone in and get them up to speed as fast as you can in order to move on to doing things that drive your business forwards. To that end, older, experienced people are very often better than younger people because they've already proven they can do the job.
[1] 44 isn't old.
A rare example of a hyper-focused older person[1] isn't a reason to hire older people. Hiring is about filling a position with someone capable of doing what's necessary. It's not about finding someone exceptional. You want to get someone in and get them up to speed as fast as you can in order to move on to doing things that drive your business forwards. To that end, older, experienced people are very often better than younger people because they've already proven they can do the job.
[1] 44 isn't old.
"won't have that level of focus and determination"
More like they won't have that level of focus and determination for a poorly run project - so it's not that they can't it's more that they won't see the benefits to them of that level of dedication.
NB I am 51 and quite happy in a technical role.
More like they won't have that level of focus and determination for a poorly run project - so it's not that they can't it's more that they won't see the benefits to them of that level of dedication.
NB I am 51 and quite happy in a technical role.
On the other hand, however, physical decline is more rapid than mental decline and we're talking about a middle-aged man able to play with the best pro athletes in the world -- seems as clear an example of any of experience trumping raw youthful energy. Peyton Manning's last season or two seems like another good example.
Well it was not meant to be countered, it is meant to be inspirational. Some say a statistical anomaly, others would say a hero.
I do agree with your expanded point, by the way. Would just add that the veterans can bring that and more; the right person can inspire & impact the performance of everybody on the team.
I do agree with your expanded point, by the way. Would just add that the veterans can bring that and more; the right person can inspire & impact the performance of everybody on the team.
Perhaps it's anecdotal too but I work in mainframes (myself being 38) with both younger and older colleagues and the ones that are older seem to be far more focused and determined (perhaps "work ethic" is the most apt word for it) than the younger ones. I can even feel it myself looking back.
I have noticed a lot of pro downhill mountain bikers are around the same age as me - early 40's.
Great idea but I'm not sure it's a good idea to post non-green jobs at all.
This is an AWESOME idea and I totally appreciate both Tim's original article on the subject and your efforts on this job site.
As a CTO I have long appreciated real world knowledge and experience over inexperienced, cheap, eagerness. Our employee's are all 30+, most have families and I believe that leads to well balanced and focused employee's. That is not to say I would not hire a younger employee but with age comes the kind of experience you need when building a new company quickly.
To be honest the "we work hard and play hard - we are a family" line would have put me off of a role even in my early 20's. Just because I want to work hard, it doesn't mean I want to always be hanging out with a team, I want a life as well.
I actually think that the ageism in tech is a result of it being a young industry. As more and more dev's go grey the problem will resolve itself.
One final note I have seen here and on other places - The why not become a CTO or Start your own company suggestion is fine for those that want to but there are a large number of developers who actually _love_ being a developer and have no interest in moving up into management. That's great and I hope that as the industry matures people realise that being a developer for your whole career is a choice and not a failure.
As a CTO I have long appreciated real world knowledge and experience over inexperienced, cheap, eagerness. Our employee's are all 30+, most have families and I believe that leads to well balanced and focused employee's. That is not to say I would not hire a younger employee but with age comes the kind of experience you need when building a new company quickly.
To be honest the "we work hard and play hard - we are a family" line would have put me off of a role even in my early 20's. Just because I want to work hard, it doesn't mean I want to always be hanging out with a team, I want a life as well.
I actually think that the ageism in tech is a result of it being a young industry. As more and more dev's go grey the problem will resolve itself.
One final note I have seen here and on other places - The why not become a CTO or Start your own company suggestion is fine for those that want to but there are a large number of developers who actually _love_ being a developer and have no interest in moving up into management. That's great and I hope that as the industry matures people realise that being a developer for your whole career is a choice and not a failure.
> I actually think that the ageism in tech is a result of it being a young industry. As more and more dev's go grey the problem will resolve itself.
Tell that to devs who worked in the dotcom boom, or the PC boom before that.
Tell that to devs who worked in the dotcom boom, or the PC boom before that.
Perhaps then the issue is that all developers see a path to management as the only way to progress their career and in actual fact there is only a minority of developers who love their job enough to want to do it for their entire career?
I think this is true of a lot of devs... I have seen friends who who have gone into management because they didn't really love coding.. I've been doing this stuff since I was 9 and don't ever want to stop
Yep. I know a guy who, in his late '20s, decided that he wasn't going to be able to keep up as a coder in the long run, so he jumped to management. As long as I've known him, he's always been the kind of person who cares more about maximizing how much money he makes than any kind of job satisfaction.
Not all of us feel like that.
I actual care more about the product and how it's built, the standard it is built to and the processes used to build and manage it.
Any manager that's worth working for still codes. Once they code no more they care more about process and profit.
I actual care more about the product and how it's built, the standard it is built to and the processes used to build and manage it.
Any manager that's worth working for still codes. Once they code no more they care more about process and profit.
Many, but certainly not all. The best developer I know started his career writing software for the original Macintosh in the 80's. He's still primarily a developer.
Here's the important question: how many twenty- or thirty-something startup founders hear that and think "dinosaur who writes GOTO statements" (false), versus "awesome hacker who has been constantly seeking out the newest technologies for 30+ years" (true)?
Here's the important question: how many twenty- or thirty-something startup founders hear that and think "dinosaur who writes GOTO statements" (false), versus "awesome hacker who has been constantly seeking out the newest technologies for 30+ years" (true)?
That is an interesting point.
Once again I say in a start up I want experience. I want developers that can deliver with minimal management and who GTD rather than work twice as long to deliver tightly coupled, dependency riddled, fashionable code.
Also another point to your comment. If the founders are 20 or 30 something, is that why they are only hiring 20 or 30 something developers. It's their contacts in their network, previous co-workers and friends. Perhaps the issue with start ups in that not that higher percentage are started by 45-50 somethings. Hence it would be interesting to see the split of developers ages compared to the co-founders age.
Once again I say in a start up I want experience. I want developers that can deliver with minimal management and who GTD rather than work twice as long to deliver tightly coupled, dependency riddled, fashionable code.
Also another point to your comment. If the founders are 20 or 30 something, is that why they are only hiring 20 or 30 something developers. It's their contacts in their network, previous co-workers and friends. Perhaps the issue with start ups in that not that higher percentage are started by 45-50 somethings. Hence it would be interesting to see the split of developers ages compared to the co-founders age.
[deleted]
> As more and more dev's go grey the problem will resolve itself.
The problem with that is the rate at which young devs leave the industry before they turn grey. Some go into management, some go into business for themselves, some burn out completely, but I'm betting most won't be able to compete at the higher levels and will get squeezed out.
As those devs at the bottom age up and are expected to move up into more technically complicated senior roles, they'll find themselves overqualified for the roles they've gotten good at (building product features using framework X) and underqualified for the more technically complicated roles (designing compression algorithms, for example).
The problem with that is the rate at which young devs leave the industry before they turn grey. Some go into management, some go into business for themselves, some burn out completely, but I'm betting most won't be able to compete at the higher levels and will get squeezed out.
As those devs at the bottom age up and are expected to move up into more technically complicated senior roles, they'll find themselves overqualified for the roles they've gotten good at (building product features using framework X) and underqualified for the more technically complicated roles (designing compression algorithms, for example).
I didn't feel this kind of bias here in Berlin.
When founding FitAnalytics.com, we were three young students fresh from university, but all of us highly appreciated more senior programmers (40+) joining the team. Even if their language didn't fit our stack (C++ for a JS position), my experience was extremely positive, feeling that some programmers just get better with age, no matter the language du jour.
Regarding pay, I feel that it's actually rising with age. I'm now myself heading towards the mid-30s and I'm not concerned at all. Some of my older programmer friends make more money than me and have more fun as well.
When founding FitAnalytics.com, we were three young students fresh from university, but all of us highly appreciated more senior programmers (40+) joining the team. Even if their language didn't fit our stack (C++ for a JS position), my experience was extremely positive, feeling that some programmers just get better with age, no matter the language du jour.
Regarding pay, I feel that it's actually rising with age. I'm now myself heading towards the mid-30s and I'm not concerned at all. Some of my older programmer friends make more money than me and have more fun as well.
I think this young programmers cult is more US centric problem. Or should I say SV centric problem. I didn't notice such widespread age discrimination in Europe. I'm not that old yet (30), but I've worked with many older programmer/engineers (40+) in several companies and most of them were highly respected, well-paid and got tons of other job offers. Sure, if you are stuck in eighties programming with Assembler only and dismiss C as high level language, don't blame anybody but yourself..
Yeah, I am not having any trouble with it outside of SV. Employers see 17 years of experience and trip over themselves to hire me (and my peers, some of whom are older).
The just-out-of-college kids can build you a website, sure, but they don't get the fun (or well paying) jobs.
The just-out-of-college kids can build you a website, sure, but they don't get the fun (or well paying) jobs.
It seems to me Berlin's startup ecosystem is heavily optimized for very young people. It's awesome the immigration process is so easy, but the minimum wage requirement for IT jobs is just 38,688 EUR. Lots of companies sponsoring visas, but with wages rarely above 50k EUR, even with a relatively low cost of living, they're only attracting young singles willing to sacrifice in order to get a blue card. And from the job pages videos I've seen (like Zalando), they explicitly state they're looking for young talent, and of course the ping-pong table propaganda (love that term!) is pretty standard.
Zalando is a bad example. First of all, it's not a startup, and certainly not part of any startup scene. Secondly, it's not exactly the best place to work at, same goes with any Rocket Internet company for that matter.
I do agree that a lot of young startups are more friendly to young people. But the tech scene in general is okay. I don't think it's difficult to find work as a senior here. I get 90k+ offers on a regular basis for attractive positions and interesting technologies to work on.
I do agree that a lot of young startups are more friendly to young people. But the tech scene in general is okay. I don't think it's difficult to find work as a senior here. I get 90k+ offers on a regular basis for attractive positions and interesting technologies to work on.
Hey, is it possible to add the ability for other countries to post?
We are a young and small British company who are getting very frustrated at having too many inexperienced applicants!
We are a young and small British company who are getting very frustrated at having too many inexperienced applicants!
Posting things like that and not having a URL/email in your profile is a missed opportunity.
This is neat, I would request that it could be international though.
Restricting jobs to just US states is limiting, especially as many of the companies listed do hire internationally too.
Just add "Not applicable / International" to the states drop down, and a Country picker.
Restricting jobs to just US states is limiting, especially as many of the companies listed do hire internationally too.
Just add "Not applicable / International" to the states drop down, and a Country picker.
Nice idea, but the site itself is clearly copied from https://weworkremotely.com/jobs/new -- even down to the segment headers. The only notable change is setting the font family to monospaced...
They look nothing alike.
The HTML structure is different
The CSS is different.
What limited JS exists is different.
The layout of each list item is different.
The only similarity, is that it is a list of jobs grouped by location and date. But that is a pretty obvious common pattern for a job site and hardly represents plagiarism.
The HTML structure is different
The CSS is different.
What limited JS exists is different.
The layout of each list item is different.
The only similarity, is that it is a list of jobs grouped by location and date. But that is a pretty obvious common pattern for a job site and hardly represents plagiarism.
Check the new post page I actually linked to! All text is almost a verbatim copy. I'm not accusing of plagiarism (I didn't mention the word), but just notice the similarities, even down to "Example: Send a resume to [email protected]" and the category listing.
Here, see them side by side: http://imgur.com/a/9Rclx
Here, see them side by side: http://imgur.com/a/9Rclx
Macuyiko has a good point.
I don't know who copied who, but it's quite clear that those pages are way beyond just coming from the same idea. That text is far too verbatim.
Makes sense. An advantage with us Old Geeks is we don't like to re-invent the wheel ;-)
How is 35 considered old?
Within the Silicon Valley bubble. No other place would think like that.
(Not that it really matters, but I'm 27...) A few things came to me after reading the post:
Firstly, how this situation shared by the OP and many others is pure insanity. That the very people who grew up with this technology during the baby years are now struggling to have a place now that it really has taken off.
Secondly, for those in their mid-30's and onward, to realize how immensely skilled they likely are at writing (if not already recognizing this fact). One of my favorite parts of staying up to date in this industry is getting to read every and any type of work/post/article from the older guys (still must admit that 37 doesn't feel old to me). Because your time was spent communicating primarily electronically, this skill has spilled over into creative writing and all other forms, which makes for incredibly well-written pieces which keep me going to this very day. So thank you for that.
Thirdly, how amazing it is that a person can now come up with an idea, build out the details and launch the website within 24 hours if truly determined. Loved the website, definitely think that as younger generations start to take advantage of the current tech and build their own on top of it, that there will be a need to differentiate between the various abilities/experience of devs.
Nice work.
Firstly, how this situation shared by the OP and many others is pure insanity. That the very people who grew up with this technology during the baby years are now struggling to have a place now that it really has taken off.
Secondly, for those in their mid-30's and onward, to realize how immensely skilled they likely are at writing (if not already recognizing this fact). One of my favorite parts of staying up to date in this industry is getting to read every and any type of work/post/article from the older guys (still must admit that 37 doesn't feel old to me). Because your time was spent communicating primarily electronically, this skill has spilled over into creative writing and all other forms, which makes for incredibly well-written pieces which keep me going to this very day. So thank you for that.
Thirdly, how amazing it is that a person can now come up with an idea, build out the details and launch the website within 24 hours if truly determined. Loved the website, definitely think that as younger generations start to take advantage of the current tech and build their own on top of it, that there will be a need to differentiate between the various abilities/experience of devs.
Nice work.
I'm 41. Must make me ancient. :)
I completely agree with the OP. About 10 years ago I created a very focused professional blog to improve my writing even though I'd already written an O'Reilly book, just as an excuse to hone my skills.
I just created a blog series about building your own language in JS, just because I've always wanted to do it. There's definitely freedom that comes with age. (and goes away with small children)
https://www.pubnub.com/blog/2016-09-26-4-tutorials-create-la...
I've found that some good engineers find a role as developer evangelists, using both their technical and writing skills. Maybe check out DevRelCon.
http://devrel.net
I completely agree with the OP. About 10 years ago I created a very focused professional blog to improve my writing even though I'd already written an O'Reilly book, just as an excuse to hone my skills.
I just created a blog series about building your own language in JS, just because I've always wanted to do it. There's definitely freedom that comes with age. (and goes away with small children)
https://www.pubnub.com/blog/2016-09-26-4-tutorials-create-la...
I've found that some good engineers find a role as developer evangelists, using both their technical and writing skills. Maybe check out DevRelCon.
http://devrel.net
>(still must admit that 37 doesn't feel old to me)
Same; I find it a bit terrifying that 35+ is considered 'old' in our industry...
Same; I find it a bit terrifying that 35+ is considered 'old' in our industry...
I'm 41 and I still don't feel old even though I work with a few people who are 10-15 younger than me.
We tend to think of old programmers as these ancient neckbeards who write COBOL and FORTRAN and grew up on usenet programming PDP machines; but the reality is that 40+ year old programmers today were kids in the 90s, were in their 20s when languages like JS, Python and PHP became popular, and played quake 3 in their early twenties.
BTW I'm not doing straight-up programmer work, more of senior architect type roles in the past years, so it might be more "acceptable" in the industry to still be spending time with an IDE at my age in this context.
We tend to think of old programmers as these ancient neckbeards who write COBOL and FORTRAN and grew up on usenet programming PDP machines; but the reality is that 40+ year old programmers today were kids in the 90s, were in their 20s when languages like JS, Python and PHP became popular, and played quake 3 in their early twenties.
BTW I'm not doing straight-up programmer work, more of senior architect type roles in the past years, so it might be more "acceptable" in the industry to still be spending time with an IDE at my age in this context.
It's not, but he has to call himself old to give his business idea credibility. (which I think is fair, by the way)
[deleted]
I dont think its as much a business-motivated thought, as it is an observation about there being a very distorted age spectrum associated with working in tech-related industries.
I'm starting to think that the way things worked is that older people realize that the best way to get ahead is to exploit younger inexperienced workers who don't yet know their own value and power, whether it's as employees or through being a landlord rentier.
That doesn't work so well anymore when the young can build their own web business without any of the contacts and wisdom required before. My generation (x) are going to have to keep working a lot longer.
That doesn't work so well anymore when the young can build their own web business without any of the contacts and wisdom required before. My generation (x) are going to have to keep working a lot longer.
And so is theirs since there is only so much space for successful businesses and so many of them fail. It's even worse because small, nimble companies can do the jobs of many companies now so you have to be even better to succeed and stay on top.
Thank you so much! Made my day with this comment, more than the upvotes even.
I am female, over 40 and an engineer with some management experience under the belt. When I go to event in SF (Valley is still better), I know that I am an outlier. One of the odds that deters conformity of the data model.
I am happy to break the mold and willing to do it.
A competent old geek is able to set up properly and very quickly but the day-to-day huffing & puffing implies a mix of stamina and boredom, that's why ping pong as a culture fit.
I think Slack and Pando are actively hiring more experienced developers. Think luckily we will see this trend continue.
[deleted]
I'd love to see this expanded to London, as someone who is fast approaching old geek status.
I find it troubling to hear that a 37 year old calling themselves old. There is no place for ageism in this world. Everyone has their own merit and it's got nothing to do with their age.
[deleted]
As a programmer in my 60s, my (rather obvious) advice is to save and invest throughout your career so you have financial flexibility as you get older. I still very much enjoy working but when I have unbooked time I really enjoy that also.
It also helps to have great hobbies. I enjoy writing (I am finishing up a Haskell book, and I have a partially written book on cognitive science that will get finished some day), I take many online classes, read a lot, hang out with friends and family, hiking, kayaking, etc.
As we get older we do slow down. I don't charge very much money anymore as a consultant and I am careful to only take work appropriate to my skills. Now when I write, I do so at a slower pace.
There is a natural order in life and I accept that.
It also helps to have great hobbies. I enjoy writing (I am finishing up a Haskell book, and I have a partially written book on cognitive science that will get finished some day), I take many online classes, read a lot, hang out with friends and family, hiking, kayaking, etc.
As we get older we do slow down. I don't charge very much money anymore as a consultant and I am careful to only take work appropriate to my skills. Now when I write, I do so at a slower pace.
There is a natural order in life and I accept that.
This is the type of humility experience buys you and companies should be benefiting from. Beautiful piece.
You have to be careful to not sell yourself short. Someone with your level of experience is more likely to avoid pitfalls and look at the bigger picture which is very valuable. A slower pace may result in fewer bugs, resulting in lower overall costs.
> I am finishing up a Haskell book
I'm really interested to hear that! Have you announced this at all or written anything about it?
I'm really interested to hear that! Have you announced this at all or written anything about it?
Hey, I noticed a couple of things you might wanna improve in your leanpub profile page:
1. The first sentence has the word "Consultant" twice in a row
2. The first paragraph mixes first and third person, i.e. "Mark Watson is an awesome programmer. I use a bunch of techs"
3. The profile pic is stretched horizontally
Thanks, I will edit that right now.
Awesome. Golden advice.
We need role models to make this a fulfilling career in the long run too.
We need role models to make this a fulfilling career in the long run too.
I wished something similar would exist in Germany too. Maybe I should start a oldgeekjobs.de!
My 2 cents...
1 - The key to avoiding age discrimination is looking for a boss your age or older. Nothing stops the applicant from pre-selecting companies this way. This is also true if you have kids.
2 - There's less age discrimination ("cultural fit") in the Peninsula than SF because execs are more likely to have families.
1 - The key to avoiding age discrimination is looking for a boss your age or older. Nothing stops the applicant from pre-selecting companies this way. This is also true if you have kids.
2 - There's less age discrimination ("cultural fit") in the Peninsula than SF because execs are more likely to have families.
>The key to avoiding age discrimination is looking for a boss your age or older. //
So age discrimination is how you avoid age discrimination ... hmmm.
So age discrimination is how you avoid age discrimination ... hmmm.
How much do people figure this problem is specific to the Bay Area?
[deleted]
Interesting idea, and I see age discrimination at my tech company every day, but I think the name is pretty lame and I can see it probably exacerbating the issue.
Nice site but it's very US-centric. Opportunities are available all around the world, why limit to only US states/cities (I have a whole bunch of jobs in Amsterdam that I could share if only it was possible!)
At 33, with over a decade of experience as a professional software engineer, I have no interest working for a team that values long hours over steady productivity, elegant solutions, and thoughtful architecture.
I know that plenty of companies have been built "quick and dirty", but honestly I think any company, regardless of size or stage, can benefit from someone with experience gained from building real applications.
I live in NYC, not the valley, so maybe attitudes are a little different here, but I have no trouble finding work at companies that value my experience.
I know that plenty of companies have been built "quick and dirty", but honestly I think any company, regardless of size or stage, can benefit from someone with experience gained from building real applications.
I live in NYC, not the valley, so maybe attitudes are a little different here, but I have no trouble finding work at companies that value my experience.
My experience is that a lot of the companies in the valley that are run by young people are very immature. The good companies hire a wide spectrum of experience levels.
"Reading between the lines," I think the original poster needs to be a bit more selective about where he applies.
"Reading between the lines," I think the original poster needs to be a bit more selective about where he applies.
If you want long career in programming you should really do serious career planing during your 20s to make sure you check all important boxes: correct technologies, mix of different kind of companies, team sizes and roles. Otherwise you might get into complicated position down the road.
I am in the early 30s and on top of my ability, but I don't see my future too bright from here. 10 years ago I make decision to do freelancing and work strictly alone. It was blast, but once my stream dry out I don't think I will ever find actual job: guy in late 30s/early 40s with string of trivial or dead end projects for unknown companies, no experience working in team and such.
I am ok with it and I am having awesome time (and always had). Everybody just have to know on what career path they are and have plan B in their pocket.
I am in the early 30s and on top of my ability, but I don't see my future too bright from here. 10 years ago I make decision to do freelancing and work strictly alone. It was blast, but once my stream dry out I don't think I will ever find actual job: guy in late 30s/early 40s with string of trivial or dead end projects for unknown companies, no experience working in team and such.
I am ok with it and I am having awesome time (and always had). Everybody just have to know on what career path they are and have plan B in their pocket.
I'm 41, 42 next month, and working as a software engineer. At age 39 I was a technical recruiter who decided to become a developer. I've never felt my age has been a significant factor in getting work.
What has been a lot tougher is learning how to get a job I really want. It turns out there's no substitute for being good at something that makes other people money. If you don't focus on making yourself marketable, your going to have a hard time finding not-crappy development work at age 22 or 82.
From late 2013 to late 2016, I burned through several dev jobs that drove me bonkers, or I drove them bonkers. Then I got better at figuring out what kind of job I want, what work I'd have to do to get that job, and which jobs to avoid.
In February I found a job opportunity I actually like, actually got the job, and now I'm super happy. My teammates are in their 20s, 30s, and 50s. Age differences are never an issue. If anything, they are an asset.
What has been a lot tougher is learning how to get a job I really want. It turns out there's no substitute for being good at something that makes other people money. If you don't focus on making yourself marketable, your going to have a hard time finding not-crappy development work at age 22 or 82.
From late 2013 to late 2016, I burned through several dev jobs that drove me bonkers, or I drove them bonkers. Then I got better at figuring out what kind of job I want, what work I'd have to do to get that job, and which jobs to avoid.
In February I found a job opportunity I actually like, actually got the job, and now I'm super happy. My teammates are in their 20s, 30s, and 50s. Age differences are never an issue. If anything, they are an asset.
"correct technologies". hah, good luck. if any of us had a crystal ball we would be billionaires, not still coding.
It is very simple if you want to be employable person, just stick to trendiest and coolest stuff and switch when there is market demand for new tech. For past decade thats like Java/PHP -> Rails -> Objective C -> Node.js (or whatever).
The point was that you should plan in advance if you want to be employeable and make sure to not stick in dead-end job/project. If your last ten years were spent writing ActionScript for unknown company, then good luck finding new job.
The point was that you should plan in advance if you want to be employeable and make sure to not stick in dead-end job/project. If your last ten years were spent writing ActionScript for unknown company, then good luck finding new job.
What makes you think your stream will dry out? Why wouldn't you be still doing this 10-20 years from now?
Who knows, my main income streams are developing Delphi 5 applications (dead market), iPhone apps (market is changing and I see much less new gigs for solo developers) and Rails apps.
Low hanging fruits seems to be picked and each new app needs to be much better, which require bigger teams.
Low hanging fruits seems to be picked and each new app needs to be much better, which require bigger teams.
You should definitely invest in your skill set then, and learn new technologies if you want to stay in the game - but age is not the critical factor here. Perhaps you've lost your passion?
I'm about a decade older than you and I'm still continuously working on evolving my skills and learning new languages and technologies. I do it primarily because it excites me, and as an added bonus it keeps me ahead in the game :)
Actually, the career path of a consultant is from I'm seeing around me, a very solid path for older guys who love programming. I know a couple of 50+ year old guys who still get tons of work, and it seems like since they are consultants, no one cares about their "cultural fit" etc.
I'm about a decade older than you and I'm still continuously working on evolving my skills and learning new languages and technologies. I do it primarily because it excites me, and as an added bonus it keeps me ahead in the game :)
Actually, the career path of a consultant is from I'm seeing around me, a very solid path for older guys who love programming. I know a couple of 50+ year old guys who still get tons of work, and it seems like since they are consultants, no one cares about their "cultural fit" etc.
Well, that was mostly point for others to consider better planing of their career.
Personally, I am not going to be developer for much longer (unless some catastrophe happens). Income from my winery, various projects, rental properties and other businesses will soon replace my income from computer programming.
Personally, I am not going to be developer for much longer (unless some catastrophe happens). Income from my winery, various projects, rental properties and other businesses will soon replace my income from computer programming.
Oh, I read it as "plan you career as programmers" :)
Good to hear you're finding other passions. Software is my second career BTW, I only started professionally at 29 (I've been programming since age 10).
I know what being trapped in a job you lost your passion for, and can't get out of, feels like. And I feel very blessed that I found my professional path. I do know that it's not for everyone.
Good to hear you're finding other passions. Software is my second career BTW, I only started professionally at 29 (I've been programming since age 10).
I know what being trapped in a job you lost your passion for, and can't get out of, feels like. And I feel very blessed that I found my professional path. I do know that it's not for everyone.
I do like programming as a hobby and a business and I am surely going to continue doing it in next decades.
Doing programming as a job with viable long term career is another topic with quite a few landmines. I am glad I am not into this race anymore.
Doing programming as a job with viable long term career is another topic with quite a few landmines. I am glad I am not into this race anymore.
I'm pushing 40 and am starting to measure my productivity by how much code I remove in a day, not how much I write. Is anyone else feeling that way? That much of what we do is a waste of time, that perhaps software is evolving in wrong directions due to issues like income inequality (wealth and expertise being at opposite ends of the spectrum) or worse is better? Sometimes I stare at the ceiling realizing that the entirety of what I'm working on can be represented by a symlinking filesystem or Excel spreadsheet. I'm not.. tired, more like, I'm tired of witnessing everything I've ever worked on being obsoleted in 3 years because yet another framework reinvents the wheel or proprietary solution opens a new market due to vendor lock-in. How did the web of declarative interoperating data become walled gardens and SAAS? There is money to be made yes, but is this progress?
At some point, the problems fall away and it all starts to look more like the wheelings and dealings of Mad Men than computer science. Then the choice seems to be whether to make the most of things (find meaning in the unfulfilling) or take an early retirement.
I'm not worried about finding work after I'm over the hill.. I'm worried about the very real possibility of my legacy being a portfolio instead of a real contribution to the betterment of humankind - building an R2D2 or software that actually frees people from labor. Anything short of that real progress feels like a waste of time, and I understand why it might not be prudent to hire someone who doesn't have profit as a primary motive. What really keeps me up at night is the thought that the idealism I’m feeling is nearly identical to what I felt as a youth, and I don't know if something has gone terribly wrong with the state of things or if the world just passed me by.
P.S. I love my job. Really! I’m just running out of time for the future to arrive when I could be working on it now.
At some point, the problems fall away and it all starts to look more like the wheelings and dealings of Mad Men than computer science. Then the choice seems to be whether to make the most of things (find meaning in the unfulfilling) or take an early retirement.
I'm not worried about finding work after I'm over the hill.. I'm worried about the very real possibility of my legacy being a portfolio instead of a real contribution to the betterment of humankind - building an R2D2 or software that actually frees people from labor. Anything short of that real progress feels like a waste of time, and I understand why it might not be prudent to hire someone who doesn't have profit as a primary motive. What really keeps me up at night is the thought that the idealism I’m feeling is nearly identical to what I felt as a youth, and I don't know if something has gone terribly wrong with the state of things or if the world just passed me by.
P.S. I love my job. Really! I’m just running out of time for the future to arrive when I could be working on it now.
I feel very similar at times. I don't mind re-inventing the wheel if it's a much faster wheel, but typically... they hit the same pitfalls that the first wheel-builders hit.
I do love my job, but I also don't want to move to the next new, hot framework because it's new and hot. I keep wondering if this is what burnout feels like, but then when I get home and I can work on any project I want, I find that there is so much cool stuff to learn that I get excited.
I do love my job, but I also don't want to move to the next new, hot framework because it's new and hot. I keep wondering if this is what burnout feels like, but then when I get home and I can work on any project I want, I find that there is so much cool stuff to learn that I get excited.
"it all starts to look more like the wheelings and dealings of Mad Men than computer science"
Yeah, in many ways the tech field (and corporations/startups in general) are bad just parodies of themselves. But the dog and pony show still gets funding, so there are still jobs out there, so I guess it's not all bad. But after a while it does get a little hard to get all starry-eyed about some new web framework or instant messaging app.
There are still some companies that do interesting things, (depending on what you're in to) but you might have to look beyond the typical e-commerce startup. Things like robotics, artificial intelligence, new medical technology, etc. Things that actually could make the world better (though of course technology is amoral, and could always be abused to make the world worse).
Yeah, in many ways the tech field (and corporations/startups in general) are bad just parodies of themselves. But the dog and pony show still gets funding, so there are still jobs out there, so I guess it's not all bad. But after a while it does get a little hard to get all starry-eyed about some new web framework or instant messaging app.
There are still some companies that do interesting things, (depending on what you're in to) but you might have to look beyond the typical e-commerce startup. Things like robotics, artificial intelligence, new medical technology, etc. Things that actually could make the world better (though of course technology is amoral, and could always be abused to make the world worse).
Another old geezer here (43!); had a good run in my twenties and wound up in technical management a few years ago.
A couple of tips:
- The "hands on" technical skills that launched your career have capped (top salary) and declining value
- If you take time to learn / think about how the underlying technology works (vs. just cut / paste / edit code), you can master related new technologies faster than the average bear.
- It is also worth noting that technical challenges tend to repeat every couple of generations; the software developer community is operating within the same set of fundamental constraints (coder time, CPU speed, network, data, etc.), the main thing that changes is which constraint matters. And they repeat: at some point, CPU will be the constraint again and all ninja coder tricks of my twenties will matter again.
- Architecture, process design, and people herding skills only grow with time; 80% of my value as a manager consists of making unnecessary work go away (without drama). I am much better at using these skills at 42 than I was at 24.
- If you ever see an opportunity to build a side project that could turn into a business, take it. Even if you don't replace your income, this gives you additional control over the direction of your late career and skills you acquire. Note that I said side project and not startup; the intent to get more control over your direction without walking away from your day job and associated income / benefits.
A couple of tips:
- The "hands on" technical skills that launched your career have capped (top salary) and declining value
- If you take time to learn / think about how the underlying technology works (vs. just cut / paste / edit code), you can master related new technologies faster than the average bear.
- It is also worth noting that technical challenges tend to repeat every couple of generations; the software developer community is operating within the same set of fundamental constraints (coder time, CPU speed, network, data, etc.), the main thing that changes is which constraint matters. And they repeat: at some point, CPU will be the constraint again and all ninja coder tricks of my twenties will matter again.
- Architecture, process design, and people herding skills only grow with time; 80% of my value as a manager consists of making unnecessary work go away (without drama). I am much better at using these skills at 42 than I was at 24.
- If you ever see an opportunity to build a side project that could turn into a business, take it. Even if you don't replace your income, this gives you additional control over the direction of your late career and skills you acquire. Note that I said side project and not startup; the intent to get more control over your direction without walking away from your day job and associated income / benefits.
I'm 38, and I now find myself being coaxed into management. I was away from the Valley for about a decade and returned 4 years ago. My career has basically continued from where I left it despite not knowing most of the hot technologies when I returned. I simply learned them, and avoided the fads. Experience definitely helps you sidestep cargo cult development, spinning your wheels and wasting company time.
I've worked with many junior devs over the years and I can see two axes along which engineers develop: those who know/learn actual computer science and software design (the math, software patterns, etc.) and those who don't; those who learn new technologies, and those who don't. If you're in both of the "don't" categories, your career stalls after about 4-5 years.
Learning processes rather than technologies is very valuable, because processes produce things. Technologies are just the building blocks. I've seen too many developers who are one-trick ponies. They build the same systems over and over, only changing what technologies they use. "Sure, I can build you an MVC content management system in PHP!" -> "Sure, I can build you an MVC CMS in Rails!" -> "Sure, I can build you an MVC CMS in Node.js!" Those developers don't age well.
Also, like you mentioned, I highly recommend trying your hand at entrepreneurship. If you have enough process skills, you can eventually handle designing and pushing a product. You might feel uncomfortable moving away from your vim window into the meeting room, but that's where the greater rewards are. And those 20-somethings are going to help you do that.
I've worked with many junior devs over the years and I can see two axes along which engineers develop: those who know/learn actual computer science and software design (the math, software patterns, etc.) and those who don't; those who learn new technologies, and those who don't. If you're in both of the "don't" categories, your career stalls after about 4-5 years.
Learning processes rather than technologies is very valuable, because processes produce things. Technologies are just the building blocks. I've seen too many developers who are one-trick ponies. They build the same systems over and over, only changing what technologies they use. "Sure, I can build you an MVC content management system in PHP!" -> "Sure, I can build you an MVC CMS in Rails!" -> "Sure, I can build you an MVC CMS in Node.js!" Those developers don't age well.
Also, like you mentioned, I highly recommend trying your hand at entrepreneurship. If you have enough process skills, you can eventually handle designing and pushing a product. You might feel uncomfortable moving away from your vim window into the meeting room, but that's where the greater rewards are. And those 20-somethings are going to help you do that.
"You might feel uncomfortable moving away from your vim window into the meeting room, but that's where the greater rewards are"
Greater financial rewards, maybe. But not necessarily greater intellectual or emotional rewards. Not everyone's cut out for or enjoys management or running a business.
There are people who just love getting their hands dirty in tech and hate meetings, power point presentations, kissing up to and hobnobbing with upper management, making up budgets and writing reports, herding cats, giving pep talks, dealing with HR issues, and the rest of the things that managers often have to do to be "successful".
I'm happiest when I can just go nose down working on interesting technical problems, when I'm collaborating with other engineers on the same, or mentoring junior engineers, with all the corporate BS taken care of by my manager.
Greater financial rewards, maybe. But not necessarily greater intellectual or emotional rewards. Not everyone's cut out for or enjoys management or running a business.
There are people who just love getting their hands dirty in tech and hate meetings, power point presentations, kissing up to and hobnobbing with upper management, making up budgets and writing reports, herding cats, giving pep talks, dealing with HR issues, and the rest of the things that managers often have to do to be "successful".
I'm happiest when I can just go nose down working on interesting technical problems, when I'm collaborating with other engineers on the same, or mentoring junior engineers, with all the corporate BS taken care of by my manager.
"Not everyone's cut out for or enjoys management or running a business."
That type of thinking will do you in. If you can take technical resources and produce a functioning system, then you're cut out for management. The people problems you'll encounter are largely irrelevant. Learning your charges' quirks, dislikes and styles is like learning a new language or API.
And if you believe in Alan Turing's compelling philosophical argument that people are just fleshbound Universal Turing Machines, then it's easy to carry over from development to management. You just end up putting a fleshy, slower, intelligent computational layer between you and the dumb, fast calculators you normally solve problems with. Program the people to program the machines. Abstraction is a core concept in development.
At some point you'll see that you can create bigger things by commanding a team or department. A single person rarely ever makes a huge contribution on their own.
That type of thinking will do you in. If you can take technical resources and produce a functioning system, then you're cut out for management. The people problems you'll encounter are largely irrelevant. Learning your charges' quirks, dislikes and styles is like learning a new language or API.
And if you believe in Alan Turing's compelling philosophical argument that people are just fleshbound Universal Turing Machines, then it's easy to carry over from development to management. You just end up putting a fleshy, slower, intelligent computational layer between you and the dumb, fast calculators you normally solve problems with. Program the people to program the machines. Abstraction is a core concept in development.
At some point you'll see that you can create bigger things by commanding a team or department. A single person rarely ever makes a huge contribution on their own.
Ok, so this is an advertisement. It'd be nice if people could clearly label things for what they are.
I'm glad someone created this service and I hope it succeeds and sticks around. Since it won't/can't fix everything, here are my suggestions for dealing with ageism in technology:
1) Try to make your fortune early. Most won’t, but try anyway. Better to have given it a shot in your twenties/thirties/maybe forties, than to sit around at 56 wondering what you’re going to do with yourself.
2) Never stop learning. Everyone has to become lifelong learners in this new hyper-competitive economy. Even moreso for those with traditional “disadvantages” like being considered too old. Keep up with trends, keep reading those whitepapers, go back and review the basics every so often (this is a good idea anyway, IMO), learn at least the basics of the new whiz-bang thing that comes out (even if it’s just the “hello world” equivalent), and generally keep yourself “interview ready.”
3) Physical appearance matters. They may not be able to ask your age, but they can look at you, and they’ll form an opinion either consciously or subconsciously; though many find this incredibly distasteful, it is the reality. That means consider carefully whether smoking/alcohol/other intoxicants that affect your physical appearance are worth it. It behooves you to keep a regular exercise schedule. Cosmetic surgery is also an option; there are many tells for age you can fix: eyelid and eyebrow droop, under-eye and various other facial lines, hanging chin. Hair dye and grafts are also worth considering, as a receded hairline and whites/grays are obvious tells.
4) It probably goes without saying to keep up your professional network.
5) Another distasteful one, but perhaps worth thinking about: if you’re someone who is in the age bracket that is often considered “very likely to have a family,” but you don’t (especially if you don’t ever plan to), state it. Signaling that you don’t have large, difficult-to-discharge obligations could give you the edge you need; you might get mentally re-bracketed. I haven’t tried this one, since I’m not yet in the bracket nor do I appear to be, but I would probably do so if I were.
6) Companies that are truly hard up for good people (and not just the “we can’t hire (at the wage we wish to pay)” companies) will just have to be more flexible. Maybe they already are.
Until we can fix the social / economic issues that underlie (some parts of) ageism, the above might help someone dealing with it on the ground.
1) Try to make your fortune early. Most won’t, but try anyway. Better to have given it a shot in your twenties/thirties/maybe forties, than to sit around at 56 wondering what you’re going to do with yourself.
2) Never stop learning. Everyone has to become lifelong learners in this new hyper-competitive economy. Even moreso for those with traditional “disadvantages” like being considered too old. Keep up with trends, keep reading those whitepapers, go back and review the basics every so often (this is a good idea anyway, IMO), learn at least the basics of the new whiz-bang thing that comes out (even if it’s just the “hello world” equivalent), and generally keep yourself “interview ready.”
3) Physical appearance matters. They may not be able to ask your age, but they can look at you, and they’ll form an opinion either consciously or subconsciously; though many find this incredibly distasteful, it is the reality. That means consider carefully whether smoking/alcohol/other intoxicants that affect your physical appearance are worth it. It behooves you to keep a regular exercise schedule. Cosmetic surgery is also an option; there are many tells for age you can fix: eyelid and eyebrow droop, under-eye and various other facial lines, hanging chin. Hair dye and grafts are also worth considering, as a receded hairline and whites/grays are obvious tells.
4) It probably goes without saying to keep up your professional network.
5) Another distasteful one, but perhaps worth thinking about: if you’re someone who is in the age bracket that is often considered “very likely to have a family,” but you don’t (especially if you don’t ever plan to), state it. Signaling that you don’t have large, difficult-to-discharge obligations could give you the edge you need; you might get mentally re-bracketed. I haven’t tried this one, since I’m not yet in the bracket nor do I appear to be, but I would probably do so if I were.
6) Companies that are truly hard up for good people (and not just the “we can’t hire (at the wage we wish to pay)” companies) will just have to be more flexible. Maybe they already are.
Until we can fix the social / economic issues that underlie (some parts of) ageism, the above might help someone dealing with it on the ground.
If I had a few millions under my belt, I would start a company that only employs empty nesters. Kids are out of the house usually. So you have a lot more free time.
You have great experience, you know how to work with people, you know how to get things done, you have probably worked in 40 different techs.
If you are writing software at this age you do it for love, not for money. I love to create, and software leads to the least cuts, burns, and pulled muscles of any career or hobby I have pursued!
You have great experience, you know how to work with people, you know how to get things done, you have probably worked in 40 different techs.
If you are writing software at this age you do it for love, not for money. I love to create, and software leads to the least cuts, burns, and pulled muscles of any career or hobby I have pursued!
A particularly strange thing about SV ageism is that some of the same people who think a 40-year-old is useless also hope to live forever. (Singularity, longevity breakthroughs, whatever.)
What do they expect to be doing at 1000 years old?
The explanation that springs to mind is that young techies lured by longevity expect to be part of "the only generation". Anyone older is too out of touch, and younger generations basically won't happen as immortals can't have kids nilly-willy. So the world would be eternally ruled by a cabal of geriatric techies born around 1990. Now that's a dystopic thought!
What do they expect to be doing at 1000 years old?
The explanation that springs to mind is that young techies lured by longevity expect to be part of "the only generation". Anyone older is too out of touch, and younger generations basically won't happen as immortals can't have kids nilly-willy. So the world would be eternally ruled by a cabal of geriatric techies born around 1990. Now that's a dystopic thought!
Every time I read a post on here about ageism and that sort of crap in SV, I feel obligated to gloat ever-so-slightly that not all VC-backed, small, fast-growing, interesting startups out here fall into that mold.
I've been extremely lucky to have joined what I see as the least ageist group of people I've ever worked with. Our CEO is in his late 40s. One of our engineers is in her 20s. One is in her 50s. I'm 38 and on the younger end of the curve, and that's totally, totally cool.
We have lives outside the office and go home at night. If we feel like working on the weekends, we do, and if we don't, we don't. We have the occasional happy hour after work (like, every few months), and nobody is ostracized if they have other plans.
Sorry for the shameless self-promotion, but I think it's important to remind everyone that the culture of 20s-or-bust has exceptions, the culture of work-or-die has exceptions, and the culture of your-life-is-your-startup most definitely has exceptions.
I wish more startups followed suit.
(ps - https://www.scalyr.com/company in case you don't believe me!)
I've been extremely lucky to have joined what I see as the least ageist group of people I've ever worked with. Our CEO is in his late 40s. One of our engineers is in her 20s. One is in her 50s. I'm 38 and on the younger end of the curve, and that's totally, totally cool.
We have lives outside the office and go home at night. If we feel like working on the weekends, we do, and if we don't, we don't. We have the occasional happy hour after work (like, every few months), and nobody is ostracized if they have other plans.
Sorry for the shameless self-promotion, but I think it's important to remind everyone that the culture of 20s-or-bust has exceptions, the culture of work-or-die has exceptions, and the culture of your-life-is-your-startup most definitely has exceptions.
I wish more startups followed suit.
(ps - https://www.scalyr.com/company in case you don't believe me!)
I'll chime in here. I work for a startup with two co-founders, one in his 50s and one in his 40s. I'm in my 30s and have two developers in their 20s.
The founders are smart and know how to interview for talent, not age.
The founders are smart and know how to interview for talent, not age.
I don't know if this has already been observed... but that fateful hiring decision (the lack of cultural fit with the 20-something brogrammers) sounds like a great one: there evidently was poor cultural fit.
I know that you believe your experience is valuable and your perspectives correct. If you didn't, you wouldn't hold those perspectives. But likewise, the exact reason these people are starting their own company versus going and working under you at Xerox is probably because they disagree with your approach.
I don't profess to know what the right answer is here. But I am very skeptical of claims of age discrimination when the author also says that these young 20 somethings don't know what they're doing and don't appreciate the hard won lore an older developer can bring. This clearly undermines the age discrimination notion, because it indicates that there is an attitudinal difference, and that difference could well be a net negative and a thoroughly reasonable thing to hire based on.
Again, this isn't intended as a judgement on who has the right perspective. I think many (not all) younger engineers would have fuller perspectives if they had more hard won experience, but I also think many (not all) older engineers may have a bias toward BigCo approaches that are at a different place with regard to the trade of between quality and speed to first version. But a lot of people start companies because they want to do things their way. Complaining about the way they choose (outside of things that are actually illegal) seems futile.
I know that you believe your experience is valuable and your perspectives correct. If you didn't, you wouldn't hold those perspectives. But likewise, the exact reason these people are starting their own company versus going and working under you at Xerox is probably because they disagree with your approach.
I don't profess to know what the right answer is here. But I am very skeptical of claims of age discrimination when the author also says that these young 20 somethings don't know what they're doing and don't appreciate the hard won lore an older developer can bring. This clearly undermines the age discrimination notion, because it indicates that there is an attitudinal difference, and that difference could well be a net negative and a thoroughly reasonable thing to hire based on.
Again, this isn't intended as a judgement on who has the right perspective. I think many (not all) younger engineers would have fuller perspectives if they had more hard won experience, but I also think many (not all) older engineers may have a bias toward BigCo approaches that are at a different place with regard to the trade of between quality and speed to first version. But a lot of people start companies because they want to do things their way. Complaining about the way they choose (outside of things that are actually illegal) seems futile.
> It’s not easy getting a job at a Silicon Valley startup of twenty-somethings when you’re a 37 year old programmer like me.
[CTO drives up in an Uber, lowers the window]
CTO: "Old woman!"
You: "Man!"
CTO: "Man, sorry. Who here knows React?"
You: "I'm 37, I'm not old!"
Older geeks don't buy into this ping-pong table propaganda. Tech companies probably won't be able to squeeze all the extra work out of us in the name of passion and culture. I guess the question is, can experience/skill/efficiency really out-produce a legion of young programmers who are willing to work 1.5-2X the hours? I have no idea.