Here's the thing, the software-is-eating-the-world explosion really took off in the early 90's (or at least that's when myself and a bunch of friends I knew got into it). All the people that got into writing software back then are aging and most that I know aren't planning to stop. I myself am on the doorstep of my 36th birthday. For those of us that have slogged it out for multiple decades now aren't simply going to go sit at home and wish we were 20 again. The sheer number of aging engineers will cause this problem to reach a breaking point. Those of us that have been instilled with the "disrupt the establishment" ethos in the 90's and 2000's will find a new industry to disrupt...our own.
For a long time I looked around at the relative lack of 40+ developers and founders in my field and considered it worrisome; what will I do when I get to that age? do I need a massive bank of savings just in case?
But I think it's also easy to see it as an opportunity. We are staggeringly lucky generation; software is the future and it isn't going the way of mass automation or obsolescence any time soon. There is probably another two hundred years of foundational innovation left in the field, we're still just scratching the surface of information theory and what's possible. Experience is likely to increase in value.
As individuals; by cultivating just a little higher order thinking, and seeing above the surface layer of raw code, it shouldn't be hard to offer meaningful value and insight for the remainder of one's lifetime. I don't think the key is learning to "adapt", progressing from one fad language or technique to another, so much as it is to see the similarities between these fads and to understand them at a higher level of abstraction. To understand that SOA programming is the same thing as micro-kernels, or CSP, for example, and to seem to offer new wisdom by regurgitating the old.
In that spirit, I've observed that the successful senior engineers I've come to know don't decry constant change, but constant same-ness.
Interesting points but a few things I disagree with. Its not so much about offering meaningful insight as it is about being a bro you can hang out with..in a lot of cases..I.e. fitting in with the "culture". So I think the slightly older guys are going to have to find common ground to band together on because they aren't going to mesh culturally with the youngsters necessarily. Other thing about two hundred year, humans will be irrelevant within 40 years, and software development, if we were able to see into the future, will basically look like magic.. for example direct manifestations of simulated realtime imaginations of a multiperson via programmable matter.
Its not so much about offering meaningful insight as it is about being a bro you can hang out with..in a lot of cases..I.e. fitting in with the "culture".
People are talking about this a lot in the context of women too - is this "cultural fit" expectation keeping women out of the profession?
I think women in general are equally able to hang and be a bro, but in some cases it means they need to adapt, and some women are resistant to operating in a masculine space.
Sure, older engineers usually can't take the "live off my friends couch and eat Ramen for a year" risks that 20-somethings can take. There are a lot of problems that can be solved in a 40-50 hour workweek though. Problems that can be solved with near-immediate profitability, etc. Or so my gut tells me.
I think ageism in tech will mature along with the industry as well, that was the first wave and a very disruptive one, so this generation has disruption as a modus operandi.
Back then old meant something different as it was a new industry, older people didn't grow up with tech and there was a huge valley/difference between someone that gets tech and a generations before that didn't have it. Everyone below 40-50ish (and definitely everyone in their 30s and below) has had tech around their whole lives and at a more core level as it was new and attracted mainly young people then, but now it attracts all people and has had people working in it for decades (past mid 90s when the internet went mainstream, most are still doing it).
I have to say working for over a decade in tech/programming that most of the really good programmers were over 30s (and all good product developers were either close or over 30), this is because it takes 10 years to get good at anything even if you start in your teens, shipping products for 10 years can't be sped up. Someone out of college at 23-24 needs to work until 33-34 to be really good. To discard that is futile and young programmers might even be scared away from this line of work if there are no future prospects. I also believe it will be detrimental to our entire country as technology is so important now.
Funny enough in game development some of the best I have worked with were actually in their 40s nearing 50s even though it is also seen as a young industry, game companies wouldn't ship anything without experienced developers of 5-10 years, you can't get that experience and then be worthless at 35.
When there is a new industry, the people in it at that time sometimes gain more valuable lower level experience because the platforms/layer is still being constructed. So engine developers that are older were almost always better than younger because they have the core knowledge without the layers of fluff that product cycles can add. Just like back in the day hardware was more prevalent and a population of people that were in it then are sometimes better at it because they were around when it was big.
The market is also solving ageism by paying programmers better than managers many times. Noone will desire to go manage if it is a step down. There was a temporary moment in time when there were NO development managers, sales/marketing/bizdev couldn't manage it. So they NEEDED programmers to go into management to make sense of it and they are good at marketing so it stuck in the collective psyche. That has changed dramatically and I believe this will mature the industry.
Also, let's not confuse ageism for VC funding selectiveness, they will always choose younger because the term sheet is easier with younger that are less knowledgable about value. The 'problem' with older coders is they know they can ship and know their value.
Who knows, if the WhatsApp guys were younger Facebook could have gotten it cheaper. If older developers build more value, VCs will see they can flip for higher amounts and that may also help this perception problem.
Ageism isn't just a problem for older developers, it is a problem for younger developers as well in that they are smart contributors that will be shut off after 10-15 years of solid work, right when most of them will be in their prime and contributing to society.
Yep, I have around 11 years experience, and I would say I am starting to get good. I see younger colleagues and see lots of incompetence, (including mistakes I would have made a few years ago).
Can I get a payrise now? No chance.
I don't really get the pragmatism behind ageism in tech entrepreneurship. That is, in a field in which human abilities are augmented by ever-more faster computing, and in which ideas, experience, and relationships would seemingly be as important (if not much more) as youthful energy...how is it logical that its best people would solely be among sub-30-year olds? It just doesn't make any sense.
But why do they care so much about hours and not about output? I would kind of understand if this was for some web technologies since older devs might not be up to speed with the latest compile-to-JS language but I can't imagine that someone who has been writing say C++ for the last 20 years would not perform better than someone fresh out of school.
I would not call Facebook a start up anymore. They are creating their own VMs and Database systems. Most start ups don't do that. Unless that's the product.
Well I didn't call them a startup. And they are creating their own VMs and DBs which is even more reason not to hire only devs who are fresh out of school.
I did specifically state start ups. I don't live in san fransico/silicon valley, but where I live the vast majority of developers are working for small start ups and small businesses and not the facebooks of the world.
Its not meant to be accurate sampling, its hyperbole to prove a point.
But you can see for yourself. Have a look at most jobs at start ups, they're always javascript/ruby/python/fancy new framework or mobile apps to reinvent online shopping or web site analytics or something.
I think a much more charitable interpretation flies: there is a reason people invent new technology (it's better on at least one dimension than the old), and startups aren't held back by legacy considerations.
The short answer is that they can't measure output. It's extremely hard for a layman to know exactly how much value he's getting out of a programmer except through another, more skilled programmer.
I'm probably old by Valley standards (32), but I took a lot of crap for this view in my twenties. I worked for a consultancy that made money by billing my time out. They'd never tell me I had to work more, but it was heavily implied on multiple occasions that working beyond 40 hours was preferable. I asked why, as I had a series of successful deliveries, and stayed ahead of my workload. They would always terminate the conversation there.
You have to play close attention to the incentive structure of the business. The situation is arguably worse for startups if you're salaried: you're 'changing the world' so it becomes OK for the occasional 50/60 hour week.
because 90% of starts ups are just fancy websites and mobile phone apps. They don't really need highly advanced programming/maths/Machine Learning skills.
They rather have naive young developers willing to work constant overtime, to get the fancy javascript frontend web page out faster.
If I were an SV employment lawyer, I'd be making a copy of the "careers" page referenced in that article. I suspect that would look very very bad as Exhibit A in an age discrimination case against the company in general. Sure, there could be other interpretations (maybe) but...
Some companies are addicted to long hours & naive employees.
It's also a natural progression of an engineer to start off as an employee & then take an independent identity. So it's common to see older engineers become consultants & business owners; who then hire the younger, cheaper, more impressionable employees.
Guess what, there's a lot of software being written by people not in their 20s in places like Kansas City, Boston and Nashville. The world doesn't revolve around Silicon Valley.
And that's really the thing a lot of these articles miss. While 20-somethings are making software to automate burrito delivery to other 20-somethings with drones in San Francisco, there's a whole world full of developers solving real problems each day. But it's hard to convince the rest of the world that there's more to the software industry than the Bay Area echo chamber.
Edit: I know not all of Silicon Valley is doing pointless startups.
This is true. There's a perception that 20/30-somethings are the hot thing in tech because they're building the kind of consumer apps that techCrunch likes to cover.
But there are a ton of startups/developers building really cool tech - in SF and beyond - and they end to be older and more interested in real technology vs cashing out their options.
Or step into somewhere like my workplace in downtown St. Louis, a skyscraper built in 1911 renovated into modern offices.
The bootstrapped, 6-year-old former startup I work for is filled with people from their 20s on up past 50s making, selling, and supporting Software as a Service, with the developers hacking away at a RESTful API and Ember.js apps. Plus, we share the building with Kickstarted startups like Pixel Press, VC-funded startups like TrakBill, etc. and we're a couple blocks from an incubator + coworking space with 80 startups at every stage.
Being away from Silicon Valley doesn't make you automatically boring, or a cubicle farm, or even full of old people
But the benefits are definitely hard to compete with. I worked for 8 years back in South Florida, 4 at a web hosting company, another 4 at a digital media company. Having to buy pop-tarts/soda in a vending machine, 2 weeks vacation, dealing with dinosaur middle management. It's incredibly frustrating.
Now I'm in the Bay Area and I often consider getting out but in general the jobs here just have better benefits. I'm not just talking about foosball/ping pong tables. I'm talking Gourmet meals, 3-4 weeks vacation, unlimited sick time, people who want to work on interesting technology problems, great salaries plus equity.
If I decided to leave my job today, there are a ton of good options all over with the exact same comp package, because they have to to be competitive in this area. I could relocate but I'd feel I was held hostage by the other options in the area I chose to move to.
I've seen the other side and it'd take a lot for me to go back.
Nashville represent! I build mobile apps for a living and I love that the environment here is diverse and creative. Walk into a coffee shop and you see people talking, writing, and socializing - not bent over their identically sticker-covered Macbook Pros.
As an iOS dev here, you can expect to make 85-100k and spend < $1000 / mo on rent. There's also no state income tax, so you get a 9.6% bonus right off the bat. Not too bad if you ask me!
The odd thing is hiring older workers is generally a great idea. From an organisational perspective programming teams don't scale vary well so hiring less skilled people is generally a terrible long term strategy. Personally, I have worked with a few hundred programmers and I can only name 3 that where competent before 30.
Outside the valley you find a plenty of really competent programmers mostly in there late 40's along with a few people that are nearing retirement age and while often gruff tend to blow your minds. As in "we stopped testing his code years ago." Or just calling someone team _. As in you could get 15-30 people working on a project or if your lucky Bob.
Another benefit (I might be selling myself here, watch out) is that older programmers have lived through more issues. Be it management, technical, HR, etc. We have seen more. And some of us know how to steer clear of such issues, and when to interject.
Side effect this is that they don't freak out when stuff goes wrong. They've seen a lot of stuff go wrong in their lives, and they know how to work through it to a solution.
They won't necessarily know what the solution is. But that's okay.
You will see the following in experienced, good consultants as well. A lot will go wrong on a gig that is not anticipated during the initial scoping of the project. The inexperienced (often but not always correlated with youth) will "freak out". Whether it is a passive flip out like analysis paralysis or a more overt one, the end effect upon management/clients is still unpleasant for them.
Even when I was much younger in the field, I observed some of the older staff tended to have an imperturbability and unflappability about them even when presented with unexpected and unwelcome challenges (read: emergencies). They often didn't know what the solution was, but had enough taste and experience to know where to start and to start Getting Shit Done. This meant picking a likely direction of troubleshooting and just start walking a breadth-first search of causes, then a depth-first on anything turning up from the breadth-first that looked promising. Easy to describe in these antiseptic terms and comfort of your keyboard, hard for many younger developers in the heat of the moment when there is a frantic manager beating them about the ears that the company is about to go under if they don't fix this "right this damned second!".
This points out another observation I've made about managing younger developers. Do not mistake their energy level and enthusiasm for the degree of emotional and verbal abuse it requires to engage them. It might be different for other industries and positions (I doubt it), but too many times I've seen people take the easy way out and subscribe to the Management by Berating school. Also called the Management by Complaining/Screaming/Browbeating school. You can mention the dire effects some emergency has to the younger crowd to establish context, but move on from it and don't use it as a way to urge them on to fix something faster. Most younger developers simply do not possess the life experience to easily tamp down the anxieties they feel and set them aside long enough to dispassionately fix the problem at hand if there is management at their desk anxiously wanting blow-by-blow updates.
This doesn't mean you simply dump the problem in the younger developers' laps and walk away, either. Neither extreme is good for your team or organization. Lead by example with a calm approach to working the problem, either make decisions on where to start or support your senior leads with their educated guesses with where to start (and if you don't know where to start and don't have senior leads to turn to, you've got bigger problems), triage the effects with mitigation tasks, assign bite-sized tasks to the less experienced developers as your judgement advises, create a big picture view for yourself with the best information available of where your team stands with the problem, clarify the picture as you go along, and run interference from the rest of the organization's managers who Manage by Dysfunction.
A side note for younger developers. The only partial shortcut to that unflappability I've had experience with is to secure yourself 2-3 years of living expenses as soon as you can. It helps you achieve perspective, especially when a manager yells you'll lose your job over something. It isn't a replacement for experience, taste, judgement, whatever you want to call it, but it does help a lot with compartmentalizing the emotional component of facing down stressful situations at work, which takes most employees a decade or two to learn, and some don't learn it at all.
Depends on what one defines as "competent" and the problem space. A lot of colleges that the thirty and under set that I've talked with don't always have a required path in CS that teaches systems and architecture, let alone C (or assembler). So, if one expect such from someone with a CS degree, that could be an issue.
The tooling accessible to people today as opposed to those that started 10 years prior is also extremely different. Running Windows? Trumpet Winsock, understanding the win.ini, config.sys, and autoexec.bat were important. Linux - a lot of people have wasted a lot of time getting sound and video drivers (as well as xf86config files) to work right, most just work fine now. All these required a level of digging that required knowing more about the system than you may have wanted.
Not saying your point isn't valid, but it does depend on what one's definition of "competent" is.
That works both ways, though -- I went through college from 2000-2004, and aside from some brief forays into other languages (Ruby and Perl, from what I remember) we were taught exclusively in C. I had some VB experience (self-taught) from middle school, but in my day job we exclusively use C and Ada ... and I'd never really had reason to learn another language. A few years back, I decided that I should learn some new languages for a) fun, and b) the diversity that I'd need if I ever wanted out of my industry. I taught myself Java, and then the Android framework. Then C# and VB .net. What really forced me to start learning new stuff was teaching - I started teaching as an adjunct at a local college after work (the only favor that getting my MS has ever done me), and then I had learn stuff to fit with their curriculum. Anyway, my point is that it's just as easy for older people to be oblivious to new tech as it is for young people to have a complete lack of understanding of fundamentals. I actually teach binary number formats, boolean algebra, virtual machine code, etc. to my students just to make sure that they're not completely unprepared ... and I will say that your point is valid - many of them have had no prior exposure.
One is an active reverse discrimination that is attempting to tilt the balance back (often enforced with some kind of law or policy). This has all kinds of well-known problems (that arguably are larger than the benefits).
The other is a more natural reverse discrimination that comes from collecting the missed opportunities of your competitors. If your competitors reject candidates for frivolous reasons, then it's easier for you to hire qualified people. I think this is what the parent comment was doing, and it doesn't strike me as a problem.
If you are a founder and aware of this bias, it is a big advantage. But if you're a competent guy in your 50s who got laid off, it's a big disadvantage. Free market economics rarely works like the textbook says, and the man (or God forbid, a woman) looking for a job is the one searching for the needle in the haystack of (1) attractive companies (2) that don't discriminate against older employees.
He's just making an observation and a possible correlation (X competent people, 3 younger than 30), not a causation (X people were incompetent because they were younger than 30).
One of the issues that is unpopular to discuss in inertia in constraints. Experienced people have learned a set of platonic causations that they apply to pattern matched situations. When they come into a new situation, if they match patterns that don't quite fit, they'll apply old solutions to situations that are not appropriate.
Enders Game is a good allegory for this.
It's good to have diversity and meritocratic process for decision making. It's good to have different perspectives, but recognize that sometimes bad experience is worse than little experience.
A competent person would understand why the solution did or didn't work the previous times, and thus why it would or wouldn't this time.
What you're saying is that some people don't learn from their experiences. You should focus on finding out if they have. That's worth way more than hoping that this young kid will.
Smart and wisdom of experience together are as kids say... gangster. It's only when a person gives up either learning or trying and accept status quo that their ability to make a big impact can be questioned, and that can happen at any age or sometimes never with a lucky few.
>Experienced people have learned a set of platonic causations that they apply to pattern matched situations.
Good developers do use pattern matching. But good developers just use it as a way to come up with ideas, and they use their experience to judge the ideas.
There's no such thing as "bad experience", just poor reasoning skills. And mostly people will improve their reasoning skills over time. Unfortunately, not always.
>> The current research shows that people really don't make their best contributions to their field before 35-45.
Look at someone like John Carmack - before he was 35 he had done Command Keen, Wolfenstein 3D, Doom, Quake 1-3. Guys like Steve Wozniak were basically out of the business by the time they hit 35. Linus released Linux when he was 22, and started git when he was 35. I doubt guys like Marc Andreesen have written much code since they hit 35 as well.
And Federico Faggin who headed the development team for the 4004 was 30 at the time. William Kahan who was instrumental in the Intel 8087 was about 45. I can go on.
So, basically what you're saying is that young people can churn out software where you can undo your huge screwup, but if you have to get it right the first time like hardware, then you need some experience.
Experienced developers have more patterns to apply, and they have more sophisticated patterns that can be applied using differential diagnostics. An inexperienced developer might not have any pattern to apply, or may naively apply the wrong one. Sometimes that leads to re-inventing the wheel, sometimes that leads to solving the wrong problems. Errors of the latter sort are favorites for senior developers to come in and clean up.
The software industry has been growing rapidly in recent decades, and the growth has been concentrated in a few geographic areas. So employers in those areas (especially Silicon Valley, and also smaller hubs like Seattle and Boston) have to recruit a lot of their workers from other regions, as their job openings grow faster than the "organic" growth of the local worker population.
Theory: This importing of workers has negative effects on age and gender diversity, since it means a higher proportion of jobs go to people who can easily relocate for work. That includes young people (who are less likely to have kids and/or spouses) and men (who more often receive the primary or larger income in a household). I'm sure you can think of other things that are advantages or disadvantages when it comes to moving to California for a job.
There are ways to test whether this effect exists and how large it is. For example, you could compare age and gender diversity across industries. The theory predicts that age/gender imbalance is correlated with geographic concentration of employment growth for each industry. You could also see whether these imbalances are worse within industry hubs, compared to companies in the same industry outside the hubs. (Though the effect can also spread outside the hubs if it influences a culture that gets exported to the rest of the industry.)
I'll bet geographers or sociologists have published research on this subject, though I don't know enough to search for it effectively. (I found some vaguely related papers on Google Scholar, but nothing yet with data that would directly answer these questions.) There are some historical parallels of course, like gold rushes and resource extraction booms that cause new industries to grow suddenly in a particular area.
After some search, "Disruptive decisions to leave home: Gender and family differences in expatriation choices" seem relevant, and you can crawl citations from there.
Another interesting aspect to rapid growth is to note where the influx of new developers is coming from.
The need for developers is so strong that all the major tech companies are devoting resources to recruiting as soon as developers graduate.
That dynamic could account for a reasonably large part of the age imbalance in the industry. If there was a similar-sized pipeline of recently-trained developers with a more diverse age group than university students the story would likely be different.
Not so much. I'm 35, started programming at about 10 in my TI99-4A, typing games from magazines, etc. the usual stuff.
No way a 40 year old guy have more experience than me in general programming, unless he was working at Microsoft or IBM at that date, and surely they are about less than 10000 of those guys in the world. Of course there are 40 year olds that may have way more experience than me in a specific language or technology.
My point is that if computer tech is only 30 year old, then you won't find programmers with more than 30 years of experience, no matter their age.
The TI99-4/a was discontinued in 1983 as I well remember because it happened not long after I spent my savings from my paper route to buy one.
If you were using one at age 10 and are now 35 that would have been 1989/1990 or so... there were no magazines writing about it by that time. You had some old issues of the TI-99er or something?
I did the same – cut my teeth on a 4A well into '94 or so (~9 by then) using old magazines. It doesn't really matter what's "current" when you have no-one but yourself to learn with.
I beg to differ - I distinctly remember getting TI magazines well into the '90s. IIRC, there was one called Micropendium that kept publishing until 1999.
Computer technology is about 60 years old, though. There were people doing some pioneering work in the 50s and 60s, and the modern hacker culture really has its roots in the 1970s, just prior to the rise of personal computing.
There was lots of stuff going on with the DEC minicomputers, LISP machines, early UNIX systems, and big-iron mainframes long before most of us were even born, let alone getting our starts on TI-99s, Apple IIs, and Commodore 64s. And let's not forget that the people who were creating those early home-computer platforms were themselves all from the previous generation.
Would you turn people like Steve Wozniak or Al Alcorn or Ken Williams away from your new startup? You'd be a fool if you did. The basic architecture of computers hasn't changed at all since they did their most important work, and the cognitive skillset that makes a great programmer is the same as it's always been.
In fact, I'd expect that people who cut their teeth on early systems, and had to work within narrow constraints, without a big stack of abstraction layers and frameworks, would be all the more adept at writing robust and efficient code than those who learned on modern tools. And I'd bet, with Moore's law slowing down, and with better-optimized code becoming more advantageous in building scalable systems, older programmers will soon be in higher demand.
She was definitely the first person to realize the potential that Babbage's Analytic Engine had, particularly outside of just calculating things. Babbage's design, if I remember correctly, was basically an improvement on a design he initially made to calculate trajectories for artillery teams, and most of his thoughts on what to use his computer for were "calculate (thing)". Lovelace wrote on how the computer could be programmed to solve more complex problems.
I think that it would be a mistake to say that computer science has truly been around for 160 years, though. A few people (there was also an Italian who was interested in Babbage's work, although I'm not sure what his contributions ended up being, if any) does not a field make, and the fact that any progress in it was more or less put on hold until the early 20th century (when mathematicians started working on what you could calculate or construct in a finite number of steps), and you didn't get (untyped) lambda calculus and turing machines until 1936, which is probably the best place to truly start the idea of computer science as a field. (And since you got early devices that were sort of primitive mechanical computers in the late 30s, early 40s as part of the whole Bletchley Park cryptography work by the Brits.)
A very large debate around the turn of the century was if mathematics that you couldn't specifically construct in a finite (or countable) manner were, which became particularly heated after Cantor's set theory work (showing that the real numbers were uncountable) and then things like Russel's paradox (showing contradictions in Cantor's naive set theory if you allowed sets that contained themselves). I'd argue (without firm, researched proof that it was definitely the intent and case) that the spirit of early computer science (lambda calculus, turing machines, etc.), which was concerned with what you could and could not compute with a finite algorithm, came in spirit from those sorts of debates. (See finitism, intuitionism, constructivism, etc. for parts of this debate; traces of it remain in modern day mathematics with some people's concerns about if the Axiom of Choice is a valid or reasonable axiom to have)
I think you're mixing up a couple stories there, but it doesn't really matter that much. Just to fill in the details (and because the alternative is for me to start responding to work emails which I just don't feel like doing this morning): Babbage was concerned about the quality of mathmatical table books, which were used for calculations before we had modern calculators and slide rules weren't mainstream. The figures in them were computed by hand, and some were so bad there was an error on every page, which made them useless for scientific work and dangerous for industrial work. The Difference Engine was designed to print out pages of figures using a little printer attachment.
ENIAC was ininitially put to work calculating artillery trajectories, once the programmers figured out the bug where the shell kept going after it hit the ground (oops!).
The work in the late 40s was interesting, too. First, you had specialized systems, then Eckert, Mauchly, and von Neumann started working on stored program computers. They had to figure out what opcodes were needed and how they were going to be implemented. Jean Jennings Bartik's book (http://www.amazon.com/Pioneer-Programmer-Jennings-Computer-C...) is a great first-hand account of all the work (and drama) from back then.
(Not trying to short-change Bartik here either -- she did a lot of the work on the ENIAC instruction set when they converted it to a stored-program computer)
Exactly. Just like how history doesn't celebrate the names of everybody who worked for Thomas Edison, there were hundreds if not thousands of people toiling away in anonymity underneath these giants.
>No way a 40 year old guy have more experience than me in general programming
I started programming toys in 1979. [1] I started programming "modern" computers in 1981. I was selling games when I was 15 in 1983. My "real" professional experience started in 1987 with a contract to write a video game from a major publisher.
So yes, it's not hard for someone to have "more experience" than you in general programming.
OMG THANK YOU! I had one of these as a kid, but couldn't remember the name! We used to have competitions to have it go from the living room, out to the kitchen, through the table legs, and back again. I was 5 years old, and wouldn't have another programming opportunity until 3 years later when we got a C64.
Ha ha, I'm 42 and always wanted a BigTrak too. I finally bought one a couple years ago when they remade them. Sucks though it does not have the dump wagon accessory.
My grade school had a Big Trak. Loved that thing. I saw there was a new version coming out that works with a phone app and thought about getting it for my great-nephews. But there's so many interactive toys out there like it I have to wonder if they'd think it was cool.
>My "real" professional experience started in 1987 with a contract to write a video game from a major publisher.
>So yes, it's not hard for someone to have "more experience" than you in general programming.
Do you know how many people were doing that? you are way over estimating the amount of people in the world with your experience.
You said "No way a 40 year old guy have more experience than me". To disprove an absolute statement you only need one example.
That said, a significant fraction of my friends from those days were doing similar things. I won't deny that I'm particularly good at programming, but all of those friends could also claim more experience than you.
You think you have more experience than 40 year olds because you were typing in games when you were a kid? How about the people working when you were a kid? I don't know, this is sort of an incredible thing to say.
Maybe I'm not that good at english because I believe I was clear that there obviously are people with more experience than me, but there are few. IT in the 70's and 80's was a extremely small field.
30 years ago, computers were actually pretty common. The school I went to had two rooms full of computers and were teaching programming to every child as part of the maths lessons. Software was being talked about everywhere.
I've heard a number of these comments recently drastically underestimating how long computers have been around.
I'm 35 and I was doing OOP via HyperTalk and AppleSoft BASIC with a dose of 65C816 assembler before you picked up your calculator. Also, TIs were toys compared to HPs.
Well, you are "old". Yup, over thirty, you have missed the boat. Welcome to the new ageism.
FWIW, I'm 47 and was programming assembly and microcode in my youth. So I have 10 years on you. At this scale, I doubt the difference matters much. Because you are old, too.
Started programming on an Apple II which I still own, in 1983 aged 11. I'm 42 now so that's 31 years. You'd need to have started at 4. Plus by the mid eighties it's not like this was that rare. My school had rooms of computers (BBC Micros, later PCs) and the kids all had ZX Spectrums, Vic20s and Commodore 64s. There are tons of people on their 40s like that. Most CompSci and Physics undergrads who were my contemporaries at college - so also now in their 40s - followed similar paths.
So it makes little sense to suggest that it's somehow a crazy idea that someone 5-15 years older than you (in their 40s) might have a longer track record working with computers.
> I'm 35, started programming at about 10 in my TI99-4A, typing games from magazines, etc. the usual stuff.
> No way a 40 year old guy have more experience than me in general programming, unless he was working at Microsoft or IBM at that date, and surely they are about less than 10000 of those guys in the world.
You're talking about 1989, right? In 1983, there were 443,000 computer programmers and 276,000 "Computer systems analysts, scientists" in the United States alone (source: http://www.census.gov/prod/2/gen/96statab/labor.pdf).
TI99? You pussy. I'm 40 and when I was 10 used to help my Dad build homebrew z80 machines. My first programming was writing a small OS in z80 asm. Helped him build an awesome z280(that was a rare chip) transputer.
Who's more unemployable -- an older developer? Or, an older developer with noticeable plastic surgery? I suppose there's some truth in the article, but most older developers, or even just technically astute individuals, that I know would never consider plastic surgery. And, as an aside, most older developers I know would never settle for the younger developer lifestyle of sacrificing their free-time and non-tech-relationships all for some street cred, adventure and a healthy paycheck. Good older developers I know are just interested in different things.
One of the biggest indirect causes of ageism I've seen is the traditional career path forced many engineers out of engineering - there is/was an attitude at places like IBM of: "If you want to make bank, you need to go into management or sales". Years later, an engineering crunch makes engineering into "where the money is", but you largely lost a generation of technical experience that took a break of a decade or two.
My father got lucky in that he was successful in his transition out of engineering, and was 67 by the time his position went extinct, but there are a whole bunch of folks who would rather have been engineers than otherwise, but ended up missing out on a couple decades where the daily tasks of building software changed dramatically so gained less in technical expertise than they should have, and were left hanging around age 50.
I have a ton of cultural criticisms of the current tech industry, but the one thing that it is absolutely getting right is valuing creation. The damage that could have been caused by the Google/Apple cartel has been limited largely by the startup industry that, for all its faults, has as a crucial belief that the act of building things is valuable, and that people who make things are the ones who create the most value.
You mention IBM, one aspect that always bugged me was upto the mid 80's they had a thing about people with beards and was some sort of unwitten policey (never worked for them) that nobody could have a beard and any intervewing with them entailed making sure you had a good shave. I worked with a chap at RAND who went onto work for IBM porting AIX onto the mainframe (least that was the initial project he was joing for) and was somewhat begrudged that he would have to shave his beard of just to get the job irespective of his ability.
That has all changed and yet back then was accepted standards from what I could tell. More a insight into culture change but I have not heard of any agisim culture inside IBM before or now, just a beard thing, which has passed.
With that anybody have any insight as to any agisim aspects inside IBM past or present?
At some point, IBM decided catering to wall street was more important than doing real work. Take a look at Cringely's articles on IBM. I've known people that worked as contractors at IBM Almaden and as the transition was occurring, they went out of their way to not end up on the radar -- the impression I got was that management being aware of your project was a risk for being cut. This was even worse for the rank and file full timers.
IBM used to invest in it's employees. My advisor was of a generation where if you saved IBM X dollars in terms of research patents, etc, you were well supported as time went on. Additionally, they had a culture of investing in their employees. I don't know when the change happened... I want to say sometime in the mid/late 90s things shifted and have since.
Sounds about right, yes IBM did also change when they focused more in offering services. Became slower in there replies too issues but still got there. One project I came across was issue with SAMBA and logging around the year 2001 and quickly knocked up a wrapper for the SAMBA code to trap and log what was needed to be logged. Took IBM a week to confirm my 30 minute solution would work and was the right approach and then they only ended up at that conclusion after talking to Jeremy Allison.
I worked for a company once that had a suggestion box. If you made a non-anonymous suggestion that wound up saving the company money you got 10% of the savings over 2 years. While I was there no one got rich off of it but a few people got some nice bonuses. I don't understand why more people don't do this.
I worked as an intern at IBM last summer. It seemed like my entire team was a stagnant pool from the 70's. The languages were C and HLASM, 'high level assembler.' None of my managers knew anything about newer languages like Golang or Haskell. We built hash tables by converting strings to integers and then using modulus. They laughed at the idea of a Linux machine being useful as a server.
That said, most of the new hires were under 25, and most of the older people had been employees since the age of 25. But definitely the older people got all the respect.
IBM's full time offer to me was a solid 1/2 of Google's offer after stock and bonuses (over 2 years), with no room for negotiation.
Haskell was designed by a committee, so it's going to be difficult to find ages for all of them, but Simon Peyton Jones, the best known of the creators, is 56.
My parents worked a long time at IBM - Dad from about '70-'00, give or take a couple years, and Mom from '77-'86, then again in the late '90s for a few years. I don't think it was an ageism culture per se in terms of older people being less valued, but from both of them, the career advancement was in either sales or management. I don't think the vision for either was to stay technical and advance on the basis of technical ability.
There was a cultural shift internally when Gerstner was brought in - before then, there was a culture of "join us, and IBM will take care of you". Saving the company in the '80s required giving that mentality up, and it destroyed much of what, in my parents' eyes, made IBM a special place to work.
Re ageism, it depends on where you are and what you are working on. I know and have known many who have 30, 35 and 40 years in and stayed in engineering.
For development, it's all about having your niche. If your niche is stable, age isn't an issue. If your niche is going away, there's little reason to keep a 50 yr old C cubicle guy to switch to consulting, 50% travel and code the latest flavor. There's just no cruising on your laurels anywhere anymore and the market turns over much more quickly.
My observation of recent layoffs is that it's ageism in that most of the people in these jobs are well into their 50's and some into their 60's. Young is 40, and if you weren't in a critical niche, you were just as likely to go as any.
I think this is a huge part of it, folks who stop "keeping up" with the technology eventually find there is a huge amount of catching up to do. When that happens, especially if there isn't a lot of runway, it can be difficult.
I remark to folks all the time that you can take someone right out of high school, and have them spend about 2000 hrs learning about "computers" and now they are 'hot shot programmers' that are in demand. 2000 hours is a bit more than a year at 5 hours a day factor in that the math, and intro classes aren't necessary for someone who has both done the degree before and spent some years working in the field, and I suspect that any engineer taking a 6 month sabbatical could be right back to current. And completely current with the wisdom of organizational dynamics, work habits honed by years of what worked and what didn't, that person should be like gold.
The place where I feel sad is when someone says "I've been unemployed and spent the last 6 months sending out resumes and no one will call me because I'm old." Had they instead spent that six months re-tuning old talents, sending out the occasional resume, and building stuff, that seems to get people hired regardless of age.
>Had they instead spent that six months re-tuning old talents, sending out the occasional resume, and building stuff, that seems to get people hired regardless of age.
There are two problems with that logic. The first is if you have only six months of experience doing something your pay is likely to reflect that.
Second, look at it from an employer's perspective. You can hire a twenty year old or a fifty year old. They have the same experience with whatever the latest thing is. The twenty year old has the energy of youth. No wife or children. He may come in hungover occasionally but with enough Red Bull he'll bounce back by noon.
The fifty year old is slowing down. He takes drugs for his blood pressure that make him tired. He has ailing parents and teenagers at home.
Who do you think is going to be more productive? Who's going to put in 16 hour days at crunch time?
You can't play to a young man's strengths if you want to compete with young men when you're over forty. IMO you'd be better off as the last guy who knows COBOL than just like every other mobile programmer with six months of experience except older and slower.
> The first is if you have only six months of experience
doing something your pay is likely to reflect that.
My experience is building things has very little to do with the current frameworks and languages. Building a payroll system with a NoSQL back end and an AWS front end is "different" than building the same with an Xwindows client and an Oracle back end, but the things that may a payroll system "good" or "bad" often have nothing to do with the bricks and mortar and more to do with the kinds of things that typically go wrong or requirements that are left unstated. Someone with 20 years of experience writing programs will often know that part much better than someone who has yet to experience them.
> You can hire a twenty year old or a fifty year old.
They have the same experience with whatever the
latest thing is. The twenty year old has the energy
of youth. No wife or children. He may come in
hungover occasionally but with enough Red Bull
he'll bounce back by noon.
That however is what sounds like actual age discrimination, that might be like not hiring a woman because "Darn it she decides to have a kid and then what? Force me to pay maternity leave? No thank you!" or "Hire that blind guy? Really like we all we need around here is someone whose computer keyboard costs more than a Retina Macbook, No thank you!" or any number of people "not like you."
> Who do you think is going to be more productive?
Who's going to put in 16 hour days at crunch time?
That is a good question, but one where the answer might surprise you. One of them might not have to put in 16 hours a day a crunch time, and one of them might be more productive in 6 hours than the other is in 12.
But if you assume work performance based on age, gender, race, religion, or sexual orientation, you will always be doing it wrong.
Honestly I've found for the most part that those who work 6-9 hours get more done than those who work 10+. Usually those spending 10+ are playing catchup or learning a new technology at the same time.
I recently had an interesting experience interviewing with a startup (which shall remain nameless). During the interview process, we had a nice discussion about sustainable development practices, and I talked about my willingness to put in the occasional long day as needed. When we got to the point where they expected me to work 60+ hours a week for the next year, they cut me loose.
I could have probably done it, but really only 6-9 hours a day, like you say, would have been actually working on what they were paying me to work on. I'm still not sure how a schedule like that could ever have been considered sustainable for anyone who wants to have any of: a social life, family, or professional development time (going to meetups and such).
>That however is what sounds like actual age discrimination...
And? What is this article about? Do you think it's productive for older guys to cry about age discrimination when they can't find a job? All I'm saying is you play to your strengths when you're looking for a job, no matter what your situation is. And being an older guy with just a handful of years in a brand new technology is playing to your competition's strengths.
Companies that wouldn't hire an older guy as an Android programmer for $35/hr will shell out $300/hr for that same guy to teach an in-house six sigma class for two weeks. So be the six sigma guy. Does it make sense? No. Does that matter? Again, no.
>But if you assume work performance based on age, gender, race, religion, or sexual orientation, you will always be doing it wrong.
That's all very nice and totally irrelevant when you're the one looking for a job instead of the one doing the hiring.
I would still choose the 50 year old. If he has a family, he's more likely to be loyal. If he's not an alcoholic, he's much more likely to produce decent work. In fact, a programmer that has to put in 16 hour days at crunch time is either badly managed or a terrible programmer. Most experienced programmers can do as much or more work in half the time. Finally, there's the issue of experience, one where the younger programmer will always come in second. So the older programmer has the advantage in every case, as an engineer would in any other discipline.
> Who do you think is going to be more productive? Who's going to put in 16 hour days at crunch time?
I'm 31 years old, have been doing lots of crunch times of 16 hour days that lasted for weeks and I really hate this expectation and mentality.
I'm more productive than ever, even though I started saying NO to overtime, because fuck you. Yet, I've worked with plenty of beginners and when I say beginners, I'm talking about 5+ years of experience and I have been more productive then all of them, even though they've been more eager than me to work overtime.
The difference has been in the following areas:
1. less experienced engineers when facing a hard problem tend to slap some code in place that barely does what the feature request asks for, without thinking of the implications much, like the potential for accidental errors, or how that code interacts with the business logic already in place, or how that functionality will interact with future features already planned. And so every sprint, every release you end up reworking/rewriting/fixing stuff from previous releases, because a rookie skipped the due diligence and slapped a poorly thought out turd. As a consequence, that's why we have software development methodologies, like Scrum, or whatever agile bullshit is the latest fad, because process is required to get good results with average people.
2. no man can keep focusing for more than 7 hours per day on average. Yes, I've been able to stay "in the zone" for more than 12 hours occasionally, however the average for really good people is no more than 7 hours. The rest of the time is filled with "busy work", like pointless meetings, replying to email, reading HN and staring at the monitor stupidly. If you don't believe me, install RescueTime and marvel at the huge amounts of daily jerking off.
3. Solid work requires a well rested mind. I'm at the top of my game when I sleep well at night and I get great ideas in the periods in which I have a good social life.
4. I learn faster than any 20-something, because I have a solid knowledge base. For example it takes me about 2 weeks to become functional in any programming language, that's because I've already worked in production and played with about a dozen thus far and in regards to paradigms, I've already worked with them all.
> No wife or children.
5. Pity that you view that as a liability. As a father of a 4-year old boy, I can tell you, a child is the greatest motivation you could ever have, which is why I trust people with children at home more than I trust a 20-something that hasn't felt what true responsibility is like.
I'd like to know where you work that you can say "fuck you" to overtime during crunch period. Because, you know, I might like to work there. Seriously, contact me. :) My email is in my profile.
This is what I guessed before I started following profile data traces:
* bad_user would be based "anywhere outside of Silicon Valley".
* You wouldn't be.
I was right. (bad_user is in Romania, according to his LinkedIn.)
That's not to say it's easy to blow off demands of overtime outside of Silicon Valley either (I've heard horror stories about game companies), but the tech companies that you can do it at seem much more common.
It may simply be founder/executive age. When the CEO has to go coach Little League, he loses any moral high ground he had for saying you can't go play with your kids.
Yes, I'm in Romania, but I've been working exclusively with Sillicon Valley companies and have been working within startup environments for the last 5 years.
Being able to say NO is not a matter of where you work, but rather one of actually saying NO. It may not work well of course, your managers and peers might not like that, the secret being to not be at the bottom of the chain - as in, you have to be reliable and capable and work on hard enough problems as to not be easily replaceable. If you can prove that you're as good or even better than somebody doing overwork (which is entirely possible because of the reasons I outlined), then nobody will mind, as in the end it's all about the value / artifacts produced, not about the lines of code written and not about the number of hours worked.
And in my oppinion, if you can't produce value while working regular hours, then working overtime won't help anyway. And if you can't produce value with overtime, do you think your boss will keep you hired just because you're a "hard worker"? The market really doesn't care about that and your boss/manager would be an incompetent if he thinks otherwise.
Speaking of market forces, it's a mistery to me how you Sillicon Valley based developers, that live at the horse's mouth so to speak, can't easily switch to jobs that you like in case you're working in environments full of jerks. I mean, even if everybody expects you to work overtime or to do things you don't like, you can always build your own startup for Christ's sake, something that I (being outside of the US) can't easily do.
>Being able to say NO is not a matter of where you work, but rather one of actually saying NO.
That's been my experience. Companies will push and push until you say no. After that they may not give you 30% raises every year, but they're not going to fire a productive employee who refuses to put in long hours.
Eh, my personal experience has been that no one actually asks you to stay late for anything. A couple of people seem to do so without being asked, but if a deadline is missed, the reaction is generally, "Well, let's examine the process for what we're doing wrong. Are we overcommitting? Were the specifications wrong? Are the engineers being randomized too much? Did we change the specs midway through?" Etc. It's never "Oh, you didn't put the extra hours in."
In the mid '90s I had a job working in a company doing logistics software. Every Friday about 2:00 my manager would come around and say "We're really behind on our delivery, so the team is coming in tomorrow for a half day. I'll buy everyone pizza for lunch."
On Saturday, of course, things wouldn't go as expected. Many times we were still there at midnight, and he came around asking us to stay for just one more hour so we could help test the latest build. Then there were more problems, so he'd ask us to come in on Sunday. For just a half day.
This happened probably three weekends out of four the first year I was there. It got to the point people were taking Friday off because they figured each hour of vacation was actually worth three hours.
So I came to the realization it was either put my foot down or find another job, so one Friday I went into his office and said "Don't even ask me to come in on a weekend. Ever again." I thought it might cost me my job, but that was the end of it.
"They have the same experience with whatever the latest thing is."
This assumption is wrong. They don't have the same experience. Their direct experience (counted as the time they spent hacking with the latest thing) might be exactly the same, but this doesn't translate to the same effective experience / capability. When I was 20, it took me much longer to become productive with any new thing than it is now when I'm 30. A 20-year old with a 6-month experience with a new language would struggle a lot even with basic concepts. A 30 (or better 40) year old, who already knows 10 other languages and a ton of frameworks would pick it up in single days or weeks and became productive very fast, leaving him much more time to dig into the advanced concepts.
When I was about 18 years old, I struggled hard with a math proof related to number theory a teacher gave me. I never solved it then when I was at school and soon moved on to some other things. Recently, when on vacation I recalled that puzzle and started thinking about it just for fun. I solved it in a few minutes by just drawing with a stick on the sand. I never studied theoretical maths nor dealt with it professionally, so I had no direct experience in doing math proofs. Somehow, my capability now is much better than it was 10 years ago. I call it "indirect experience".
Experience is a liability. You learn all kinds of things as an engineer that quickly become obsolete. Even in the web environment. If you're still worried about hasLayout or rounding corners with images, or god forbid using tables for layout, or even setting explicit widths on your web pages instead of responsive media queries, you're adhering to obsolete ways of doing things that are hurting you more than helping.
Edit: Am I being downvoted because I'm wrong or because you just don't like what I have to say? Both are wrong reasons to downvote, but you go, you go downvote. My comment is reality. It may not be what you want to hear, but it isn't a low quality comment. I'm so tired of this silly site and it's potato filled echo chamber.
Yes, you have to continuously improve, and also recognize that the things you learned before may no longer apply. Always know why you have to do the things you do and when that isn't true anymore.
> also recognize that the things you learned before may no longer apply
You also have to learn when the things you learned before do apply. This is important because technology is cyclic. There are a constant stream of fads that many of the less experienced engineers won't be able to see alternatives to.
Experience also gives you the kind of skills that don't become obsolete, and which can't be learned in just a couple of years of practice:
- Writing reliable, maintainable and testable code
- Strategies for solving problems that are very large or very difficult
- The ability to interact well with developers, product managers, executives, customers, etc.
- Knowledge of algorithms and other fundamental things in computer science
Being a good software developer is about a lot more than just dealing with the mechanics of the particular software environment you happen to be using today.
No you are getting downvoted because you are as wrong as you can possibly get. And by the looks of it CSS focused... which I wouldn't even call engineering.
Things rarely go obsolete for one thing. Try explaining why COBAL, FORTRAN, VB6, ColdFusion, or hell more modern stuff like J2EE are still around and in good usage. Things become unpopular, often for good reason, but they don't go obsolete for well over a decade. When something costs over a million dollars to construct and its working OK then theres no reason to get rid of it. Most places can't afford multi million rebuilds because its become unfashionable.
What you also learn as you get older is most modern advances are just rehashes (often poorly as they where written over a month instead of years in a research lab) of existing ideas. Or they are nothing more than a load of premade scripts which are nice (and I'm very thankful for the ones I've used) but if you work with clients or existing stacks those often become problematic.
The new ideas that stick often take 5 years to get rolling, and another 5-10 before they sunset. I wouldn't call that quick by any stretch of the imagination. The hype moves fast... but the technology doesn't.
So separate yourself from the hype and you'll see a world moving a lot slower than you think, the given time the overwhelming torrent of new ideas starts to become a same old shit, different day scenario.
Your comment is your perceived reality, and quite frankly it's wrong. If experience is a liability then the end-game of that line of thinking is there should be zero schooling or learning of any sort. If you're not learning everything from the ground up by yourself you're getting someone else's preconceived notions drilled into your head.
I'm sure you can see how this line of thinking leads to a total logical breakdown. The issue I think you are trying to illustrate oh-so-ineloquently is that a lot of developers ossify into "what they know". Then you end up in the "I have this one hammer and everything looks like a nail" issue that is actually real. Keeping up with current trends, tools and design patterns is definitely harder as you get older, but also one of the interesting parts of the job. For those who can't or won't adapt and learn, I'm sure there will be plenty of J2EE apps to maintain over the next few decades just like there are still Cobol apps to maintain now.
You're being down voted because what you're wrong (which I agree is not a good use of a down vote). You seem like someone who doesn't realize that software technology doesn't really change, just get painted a different color. Its like a Dunning-Kruger effect for life experience.
My favorite part of your comment is that most of the things you are complaining about were considered bad practice the last time I was a professional web developer and that was going on 15 years ago.
If you are routinely running into these issues, the problem isn't with the experience of your peer group, it's with their quality.
My Web pages use tables for layout,
and each of my Web pages is exactly
800 pixels wide. It's simple. Dirt
simple.
Using tables lets me put things on the
page just where the heck I want them.
I don't know of any easier way with
HTML or CSS, and I'm not going to write
any JavaScript -- won't do that. Having
all my pages just 800 pixels wide is just
what I want for my view of a good
UI/UX for my Web site. And the Web pages
should look okay on everything with a
Web browser right up to date as of, say,
five years ago. So, I'm not going to
test my pages on several versions of
each of several Web browsers on each of
several devices and, with such simple
Web pages likely don't have to. And I
have no pop ups, pull downs, roll overs,
or anything else that has the screen
change just do to mouse movements or
anything else except deliberate user
actions.
That's the way I want the pages to be
at least for now.
I wonder if this is a 'Valley' or just a 'Startup' thing as it doesn't seem too common here in Australia in the part of the industry that I work in (defence and now gaming); though maybe I'm just lucky and have been in the right parts.
We have a massive age range all the way from 20 to 60 (I guess), with most of the better engineers in their 30s-40s it seems, though to be honest you wouldn't really know unless you asked - there are guys here that you wouldn't guess were 40.
Personally I know I'm a far better engineer now in my mid-30s than I was in my 20s and to be honest I STILL feel like a beginner excited to finally find his feet. I don't see this stopping anytime soon. I don't want to get into management and luckily don't have to and I'm sure at 45 I'll be a far better software engineer than I am now (well, I sure hope so at least :) ).
|The authors examined the high points of the careers of both great inventors and Nobel-Prize winning scientists, and they found that the late 30s were the sweet spot for strokes of genius
The gist is that this number (38ish) has been slowly creeping up over the past century; it is generally higher in those fields which require a synthesis of huge amounts of knowledge (experimentalists) and earlier among theorists. Notice that essentially no one has done anything groundbreaking in their 50s (yet).
Well, I can tell you that in the midwest, if anything, the difficult part is to find young developers. Back when I started, it was not uncommon to have 22 year-old dev leads. a 30 year-old was a dinosaur, or in management. Today, most companies around here are pretty much ignoring kids out of school, and hiring 30 somethings. Last year, I worked in a team where the youngest dev had been programming professionally for 15 years, and we weren't working with any old legacy stuff.
What has happened is that most of the bad developers that I worked with 20 years ago are working in banks or outside of development, because it's much easier to hide your incompetence in our 20s than in your 40s.
Now, Silicon Valley is full of fresh meat, and of companies whose best asset is having a guy that is fluent in venturespeak, so I am sure the experience is very different. Just like it's harder to find a .NET job in Seattle if you haven't worked at Microsoft before, given how many former Microsoft employees are available to compete with you.
I started my IT path early in the 80's working for a Goverment facility doing COBOL programminmg at the tender age of 17. Agisim back then was against young people and more the older people working in the industry. This was born out when a year later a new batch of trainee's of which one I was mentoring was actualy being paid twice what I was. This was soley due to age.
I moved on to another company and trippled my salary in the private sector, though again was told by the recruiter if I was over 21 I would of got paid at least £2k more than I was.
After a short time I moved into contracting at around the age of 19, doing COBOL work. Again I had many issues due to ageisim for being so young in what was a old generation feild. Interviews would be a complete grilling of which I excelled and shone above and with that got the work. Age was still a factor then and as a young contractor I was often dismissed by people soley due to my age. Though would always shine above them in technical ability, because I had too.
After a few years contracting and the isolation of being a contractor amongst permies(permenant staff) I would feel left out and moved back into permenant work.
Times changed, now it is the reverse and sadly I missed both boats, being at the age of 47 and with the IT feild often shafted on many managerial levels I somewhat regret not working in a building trade as many people I know did and made better money, more free time, less stress and burden. Not forgetting it is a older trade and with that TAX wise more adapt in NI contributions (National Insurance - UK thing) being a pitance on contract to IT, which is full rate. Then there was the introduction of IR35 desigend to penalise contractors in IT directly.
It still is finding it's feet and whilst law and accounts have there long standing estabilished exams of recognition, IT still does not. With any certification easily expiring in a few years and nothing holding up for a lifetimes of work.
Sadly that still prevails and IT is often the butt of all departments in many a company and often shat upon, little reward for good work that saves money over other departments who add little value.
But during my time, one event stuck out. I went for a permenant job at a company - PC Database work, Dataease and turned up at reception ontime. Was left waiting for 30 minutes then handed a form to fill out, which was basicly a HR form regergitating what was already on my CV. I then had an intervew with the HR manager. She was very curt and rude and said, that is a lot of money for somebody your age and was very dismissive and really put me off the company. I had the IT department intervew with a manager and contractor they had in who was an `expert` in the feild. Shone thru and even educated the contractor about a hidden debug mode, happily answeared the question about post codes in so much detail that it was scary (post codes same as USA ZIP codes). This resulted in a job offer before I even got home, offering me more than I was (the recruiter) asked for. I turned it down flat for a lesser paid role as the HR experience had put me off completely from that company.
So whilst agisim is a problem, that problem has gone from looking down upon young people, to looking down upon older people.
But the real issue of IT and one that will carry on for many years is one of establishment, be it certification and exams that stand the test of time akin to accountants or lawyers. Until that day, IT will always in many companies be the shat feild for many due to upper managment mentality. Which ironicly enough is the older people mostly. Younger managerment (CEO's etc) have more respect for IT and also sadly less respect for older people in IT.
With that I often wished I was born earlier or later instead of catching the shit-tide from both ends from when I was young and now older.
Ageism is a real problem, but in my opinion ageism is often cited by job seekers where the problem is something else entirely. In tech, there seems to be quite a bit of discrimination today against employees who have worked for many years at the same position, and that discrimination is typically aimed at large environments. Startups seem to be ok with hiring older engineers who bounced around and worked in startups in the past, but they usually won't give much consideration to a 50 year old who developer has spent the last 25 years at an insurance company or major bank.
Take two 50 year old engineers. The one who has had 10 jobs over the past 25 years is considered infinitely more employable than the one with 25 years at the same department of the same company.
This case isn't ageism, it's the expectation of career stagnation, yet many of those engineers with that 25 year tenure think it is. It's a leftover from the days when loyalty was tied to tenure, and loyalty was valued highly in the hiring criteria. Those days are over. Loyalty is nice, but loyalty that negatively impacts your career options (no learning or improving, inability to use marketable tech skills, etc) is foolish.
That makes a presumption that someone who spent 25 years at the same employer stagnated. I spent nearly 10 years at my first employer, but in that time I had three different positions. On my resume I have started listing it as three separate positions, which seems to confuse some people but is an accurate portrayal of my time there. I do not think one employer == one role is an accurate assumption and that "10 jobs over the past 25 years" vs. '25 years at the same department of the same company" is a false dichotomy that assumes people like me do not exist.
I'm not saying the assumption is fair, and there are certainly exemptions. I'm saying that startups tend to assume that if you've been at the same place for 25 years, there is a reason for that, and the reason is usually negative.
When you say 'people like me', keep in mind that just because you have had three different roles at one company in itself doesn't mean you didn't stagnate, just as the person with ten jobs may have stagnated.
All assumptions have some danger, and I'm not condoning the behavior. I think it's valuable to explain to people who feel they are being discriminated against based on age may be more likely associated with stagnation (actual or assumed) based on extended tenure.
I'm certainly not saying that someone who has held multiple positions has not stagnated, either, simply that fundamentally the only difference between me and someone who worked for three different companies but had the same roles as I did is merely the company nameplate. To make different assumptions based solely on that is illogical.
It's quasi-ageism, I guess, in that junior level workers are difficult to accuse of stagnation. So although junior level workers may stagnate, it may be assumed that they didn't yet. I've seen devs in their early 30s as victims of this stagnation assumption (10 years in some traditional industry).
If you've switched 10 companies in the last 25 years, then your value contains lots of stuff that was transferrable/common to different jobs; if you've been 25 years in a single tech area, then it's very likely that your key value is in-depth knowledge of that particular area - unless I need that exact area expertise; an employee with 10 different shallow expertises would be more valuable to me than 1 really deep expertise that's outside my scope.
What about 10 similar shallow experiences vs. 1 really varied experience? That is exactly the false dilemma I was talking about earlier. Changing companies does not automatically mean changing roles, and staying with one company does not automatically rule it out.
None of the judgements need to be 100% true - it's not automatically, but if it's noticeably more likely than it is this way, then it's completely valid.
Are you arguing that in that scenario it's more likely that the one-workplace worker really has better experience, or are you arguing that it's possible that he has better experience?
CV-sorting is not a maximization problem, it's a satisficing problem of getting a few good candidates to the interviews at a reasonable cost; which generally requires throwing out 90% of CVs without spending the resources to seriously investigate those people. As long as you have enough qualified candidates, factors that "often are bad, but sometimes are good" equal an automatic forward to the circular folder under HR desk.
What we need is a movement of `experienced` devs to get out there and form some companies that employ mainly older devs. I'm sure the quality from such a company would be incredible.
I found my gig by putting this on my SO Careers page: "I'm looking for a challenging position requiring significant programming expertise; preferably involving systems-level programming and/or CS theory". Open source work helped.
Older technologists are out there, but they're a bit nomadic.
I'm a 40+ engineer in the NYC metro area and I've never felt more in-demand in my life! I think it boils down to a simple idea: computer-science is a dynamic field and THE FUN PART is that you need to always be learning.
There are still some colleagues my age who still wax about the days of writing JCL for their mainframe jobs and never evolved past the 80's and perhaps they gave a bad name for others who built on their of years of experience with evolving knowledge.
I decided in 2009 to specialize in mobile, when I realized how impossible it was for the startup I was working for to find any high throughput engineers, let alone high throughput engineers with niche expertise in mobile. I think it is an advantage in some ways during interviews that I can talk about decades of awesome projects I worked on while also being among the first to ship an iPhone app or a top ranking iPad app.
As they say, luck is when preparation meets opportunity. It's my job to make myself lucky.
What was the job market like when you graduated from university? Do you think it's easier for you to get a job now than it is 10, 20 years ago? Just curious to hear your thoughts.
When I graduated from college, it was 1994. Most people who were making good money at the time were Unix C programmers so that's what I did out of school. Honestly, I felt more ageism because I was young at the time (contrary to this article) than than I ever do now as a 40+. I was getting paid a relatively low salary and was expected to work insane hours. My accountant friends were probably making more money out of school. So, I wouldn't say it was harder to find a job then, but it was harder to find something cool or interesting than it is now.
I also think I wrote kind of silly code then. I always laugh when I think about a persistent hash table I had to write and how I went out of my way to find prime numbers for M slots using Fermat's Simple Theorem (not his last theorem) and testing for Carmichael numbers. Of course, there aren't that many prime numbers in the first place and a static table would have worked just fine! I always remember this as part of my evolution from an inexperienced academic kid solving a problem that doesn't need solving vs. experience to know where to comprimise and just get it done.
Even then, I knew it was important to start specializing where the needs were evolving, which was win32 programming at the time and eventually Windows MFC programming. This all dove-tailed nicely years later when I started working on the Playstation 3, where you develop in MS DevStudio but the PS3 was essentially a Unix box. It's funny how things work out.
The only thing that sucks about being a 40+ engineer is when I say "whachoo talkin' bout Willis" or "it's tricky to rock a rhyme", half the people don't know what I'm talking about.
> Honestly, I felt more ageism because I was young at the time (contrary to this article) than than I ever do now as a 40+. I was getting paid a relatively low salary and was expected to work insane hours.
Interesting! Was it ageism or was it because you were inexperienced? This is tricky because I feel like even if younger developers are discriminated against based on their age, they might be less likely to attribute it to ageism. If this is true then I wonder if older developers are for some reason more likely to blame ageism for their career ills instead of skill obsolescence, hence making ageism seem like something that mostly affects the older devs...
It's never easier to blitz through interviews and ramp on new tech than if you've seen most/all of it before.
We're just figuring out where the old abstractions land and the syntactic sugar has made life easier.
There is a massive personality issue at play. If you love this stuff, you don't let new stuff pass you by and end up being a specialist on the dead end. You're constantly sharpening the sword... because you love sharpening swords. Staying relevant and employable is a side-effect.
Depends on the interview. I would not do well in algorithmic questions these days, because I know better than to write my own. I was good a that stuff at University, but I have never had the need to implement a linked list or hash table since.
A decision to specialize in mobile in 2009 would probably have even worked out for a 60+ engineer if they were good at it. The best way to combat ageism is to stay technically relevant. Good decision.
> The best way to combat ageism is to stay technically relevant.
As I get older, I find that is easier said than done. I still spend quite a lot of time learning new things, but I've become less interested in learning things that are immediately marketable. Learning yet another framework that is marginally different than the one I used on the last project is not the interesting pursuit it once was. At this point I would rather invest that time in something that might fundamentally change my outlook and understanding of the world, which is beneficial in a meta way, but isn't really something that you can specifically write down on a resume.
I think just showing that you are still learning makes you relevant. Displaying some level of intellectual curiosity will get attention, even if it isn't the exact framework or new shiny thing that is the latest flavor. Also shows that you can pick up new things.
That's reassuring, but... What's the average retirement age in the US? 60? And here we are consoling ourselves about still being in-demand at the ripe old age of 40.
Keep in mind that most of us aren't earning pensions and our 401Ks are earning peanuts so retirement at 60 effectively means "living on social security and whatever you managed to scrape together". Retirement will mean poverty for a great many people, I fear.
61 and climbing, but that number doesn't tell you much by itself. If you spend your career in SV as a reasonably in-demand developer and have no major life catastrophes, you might easily retire 5-10 years earlier with good money management. Partly depends on what kind of lifestyle you want in retirement, and where you plan to spend that retirement.
Come talk to me when you hit 50 :-) The "retire to Latin America" trope seems to be extremely popular amongst thirtysomethings who haven't necessarily considered what it would be like to suddenly put thousands of miles between yourself and aging parents, family, children, whatever friends you still have, etc. It just ain't that simple.
I'm sure its different for everyone, but I'm 31 and live in a 1100 sq ft condo with my wife; I could give away all our Ikea furniture in 24 hours on Craigslist and be on the other side of the world in 48-72 hours. That's just me though and how I like to live.
I'm curious about the "high throughput" part of your comment. Does that mean rapid development? Lots of lines written? or what?
I find the older I get, the slower I produce code. I spend more time thinking about the solution than coding the solution. This tends to frustrate my employers, who follow the "move fast and break things" philosophy. They think I shouldn't have to think about it, just do it.
So, I guess what I'm asking is, in your opinion, is my slowing down a problem? Or an advantage?
" team, especially one that does rapid development-"
sorry, what? any team that thinks "rapid development" actually means writing code more quickly is a team composed of idiots - I think I must be misunderstanding you?
If your code ends up coming out the other end with fewer defects and ends up costing the company less overall than when similar tasks are done by your peers, then document that and present it to your bosses.
If it's incurring a similar bug load and just gets done slower, that's a problem and they're right to be upset.
I've seen both cases before, even from very experienced people, so it's very specific to the situation.
Fourty plus segment here, work in a group where the average age is actually mid-30s despite a couple of junior people. Some of us are generalists, some specialists, all have kept abreast of assorted technologies as our careers have progressed.
The narrowest experience is actually amongst the mid/late 20 somethings in our group. I'm not sure if it is that lack of systems experience, not much exposure to C and lower level languages, or what, but they need more mentoring than what I recall needing at the same age.
I'm currently doing that for a couple of them and it is actually both challenging and interesting. Challenging mainly in how to convey tasks, teach them troubleshooting (without the hand holding), and a few other items. Interesting because we all learn differently and seeing how others approach problems either reminds me of my own trials or forces me to think out of the box on how to explain things.
Personally, I've always been a bit of a control freak when it comes to development -- I want to know system level through whatever level I am developing at. This often includes system administration, database management, etc. This has become much more challenging as new technologies come about -- so in those cases, say NoSQL, I will focus on one or two solutions rather than trying to understand each. Build a basis for the concepts, where it is useful, and then test, collect data and reevaluate.
From where I sit, I can't figure out if this is a real thing or just hype. I'm 45, and had exactly zero trouble switching jobs recently, becoming employee #15 (developer #5) at a startup that just did its A-round. They said they liked the fact that I had done a bunch of different stuff, including founding a company in the 90's, and that I had an obvious passion for what they were doing. So, I'm not (yet) freaking out about the bits of gray in my beard.
This article might more aptly be titled the brutal ageism of silicon valley. Or perhaps the brutal ageism of startups.
There are red flags that you can easily spot in a job interview or job posting that indicate that the employer wants 80-hour weeks. And who signs up for 80-hour weeks? Naive young people who don't value their time and don't have other commitments, like side projects or family.
"We work on very hard deadlines"
"Looking for someone with energy to manage all aspects of"
"We have a fast pace of development"
"We want someone completely dedicated to the vision"
It's easier to gauge over the phone or in person. It's often the way things are said that act as a trigger. If a founder works 60-80 hour weeks, it's going to be expected that you will too.
Another interesting thing that this article touches on is VCs being biased against Boston, or more broadly, biased against companies headquartered anywhere except the Bay Area.
Given the increasingly insane economics of the Bay Area they're attaching millstones around the necks of the companies they invest in. And just like with ageism the purported benefits on which they base their biases are dubious at best.
If they'd spend the time they spent getting botox on Coursera or in youtube lectures learning the current skills that are in demand, they might just see a better result.
360 comments
[ 3.5 ms ] story [ 412 ms ] threadBut I think it's also easy to see it as an opportunity. We are staggeringly lucky generation; software is the future and it isn't going the way of mass automation or obsolescence any time soon. There is probably another two hundred years of foundational innovation left in the field, we're still just scratching the surface of information theory and what's possible. Experience is likely to increase in value.
As individuals; by cultivating just a little higher order thinking, and seeing above the surface layer of raw code, it shouldn't be hard to offer meaningful value and insight for the remainder of one's lifetime. I don't think the key is learning to "adapt", progressing from one fad language or technique to another, so much as it is to see the similarities between these fads and to understand them at a higher level of abstraction. To understand that SOA programming is the same thing as micro-kernels, or CSP, for example, and to seem to offer new wisdom by regurgitating the old.
In that spirit, I've observed that the successful senior engineers I've come to know don't decry constant change, but constant same-ness.
People are talking about this a lot in the context of women too - is this "cultural fit" expectation keeping women out of the profession?
I think women in general are equally able to hang and be a bro, but in some cases it means they need to adapt, and some women are resistant to operating in a masculine space.
Back then old meant something different as it was a new industry, older people didn't grow up with tech and there was a huge valley/difference between someone that gets tech and a generations before that didn't have it. Everyone below 40-50ish (and definitely everyone in their 30s and below) has had tech around their whole lives and at a more core level as it was new and attracted mainly young people then, but now it attracts all people and has had people working in it for decades (past mid 90s when the internet went mainstream, most are still doing it).
I have to say working for over a decade in tech/programming that most of the really good programmers were over 30s (and all good product developers were either close or over 30), this is because it takes 10 years to get good at anything even if you start in your teens, shipping products for 10 years can't be sped up. Someone out of college at 23-24 needs to work until 33-34 to be really good. To discard that is futile and young programmers might even be scared away from this line of work if there are no future prospects. I also believe it will be detrimental to our entire country as technology is so important now.
Funny enough in game development some of the best I have worked with were actually in their 40s nearing 50s even though it is also seen as a young industry, game companies wouldn't ship anything without experienced developers of 5-10 years, you can't get that experience and then be worthless at 35.
When there is a new industry, the people in it at that time sometimes gain more valuable lower level experience because the platforms/layer is still being constructed. So engine developers that are older were almost always better than younger because they have the core knowledge without the layers of fluff that product cycles can add. Just like back in the day hardware was more prevalent and a population of people that were in it then are sometimes better at it because they were around when it was big.
The market is also solving ageism by paying programmers better than managers many times. Noone will desire to go manage if it is a step down. There was a temporary moment in time when there were NO development managers, sales/marketing/bizdev couldn't manage it. So they NEEDED programmers to go into management to make sense of it and they are good at marketing so it stuck in the collective psyche. That has changed dramatically and I believe this will mature the industry.
Also, let's not confuse ageism for VC funding selectiveness, they will always choose younger because the term sheet is easier with younger that are less knowledgable about value. The 'problem' with older coders is they know they can ship and know their value.
Who knows, if the WhatsApp guys were younger Facebook could have gotten it cheaper. If older developers build more value, VCs will see they can flip for higher amounts and that may also help this perception problem.
Ageism isn't just a problem for older developers, it is a problem for younger developers as well in that they are smart contributors that will be shut off after 10-15 years of solid work, right when most of them will be in their prime and contributing to society.
Sounds like an accurate statistical sampling to me.
But you can see for yourself. Have a look at most jobs at start ups, they're always javascript/ruby/python/fancy new framework or mobile apps to reinvent online shopping or web site analytics or something.
So they use whatever the latest angular clone is.
There's probably a business idea there.
Besides, I write my best code when I'm jogging. I just type it in when I get back to my desk.
You have to play close attention to the incentive structure of the business. The situation is arguably worse for startups if you're salaried: you're 'changing the world' so it becomes OK for the occasional 50/60 hour week.
They rather have naive young developers willing to work constant overtime, to get the fancy javascript frontend web page out faster.
It's also a natural progression of an engineer to start off as an employee & then take an independent identity. So it's common to see older engineers become consultants & business owners; who then hire the younger, cheaper, more impressionable employees.
Edit: I know not all of Silicon Valley is doing pointless startups.
But there are a ton of startups/developers building really cool tech - in SF and beyond - and they end to be older and more interested in real technology vs cashing out their options.
The bootstrapped, 6-year-old former startup I work for is filled with people from their 20s on up past 50s making, selling, and supporting Software as a Service, with the developers hacking away at a RESTful API and Ember.js apps. Plus, we share the building with Kickstarted startups like Pixel Press, VC-funded startups like TrakBill, etc. and we're a couple blocks from an incubator + coworking space with 80 startups at every stage.
Being away from Silicon Valley doesn't make you automatically boring, or a cubicle farm, or even full of old people
"RESTful API", "Ember.js apps", "Software as a Service", "sharing the building with kickstarted start ups".
Now I'm in the Bay Area and I often consider getting out but in general the jobs here just have better benefits. I'm not just talking about foosball/ping pong tables. I'm talking Gourmet meals, 3-4 weeks vacation, unlimited sick time, people who want to work on interesting technology problems, great salaries plus equity.
If I decided to leave my job today, there are a ton of good options all over with the exact same comp package, because they have to to be competitive in this area. I could relocate but I'd feel I was held hostage by the other options in the area I chose to move to.
I've seen the other side and it'd take a lot for me to go back.
As an iOS dev here, you can expect to make 85-100k and spend < $1000 / mo on rent. There's also no state income tax, so you get a 9.6% bonus right off the bat. Not too bad if you ask me!
Outside the valley you find a plenty of really competent programmers mostly in there late 40's along with a few people that are nearing retirement age and while often gruff tend to blow your minds. As in "we stopped testing his code years ago." Or just calling someone team _. As in you could get 15-30 people working on a project or if your lucky Bob.
You will see the following in experienced, good consultants as well. A lot will go wrong on a gig that is not anticipated during the initial scoping of the project. The inexperienced (often but not always correlated with youth) will "freak out". Whether it is a passive flip out like analysis paralysis or a more overt one, the end effect upon management/clients is still unpleasant for them.
Even when I was much younger in the field, I observed some of the older staff tended to have an imperturbability and unflappability about them even when presented with unexpected and unwelcome challenges (read: emergencies). They often didn't know what the solution was, but had enough taste and experience to know where to start and to start Getting Shit Done. This meant picking a likely direction of troubleshooting and just start walking a breadth-first search of causes, then a depth-first on anything turning up from the breadth-first that looked promising. Easy to describe in these antiseptic terms and comfort of your keyboard, hard for many younger developers in the heat of the moment when there is a frantic manager beating them about the ears that the company is about to go under if they don't fix this "right this damned second!".
This points out another observation I've made about managing younger developers. Do not mistake their energy level and enthusiasm for the degree of emotional and verbal abuse it requires to engage them. It might be different for other industries and positions (I doubt it), but too many times I've seen people take the easy way out and subscribe to the Management by Berating school. Also called the Management by Complaining/Screaming/Browbeating school. You can mention the dire effects some emergency has to the younger crowd to establish context, but move on from it and don't use it as a way to urge them on to fix something faster. Most younger developers simply do not possess the life experience to easily tamp down the anxieties they feel and set them aside long enough to dispassionately fix the problem at hand if there is management at their desk anxiously wanting blow-by-blow updates.
This doesn't mean you simply dump the problem in the younger developers' laps and walk away, either. Neither extreme is good for your team or organization. Lead by example with a calm approach to working the problem, either make decisions on where to start or support your senior leads with their educated guesses with where to start (and if you don't know where to start and don't have senior leads to turn to, you've got bigger problems), triage the effects with mitigation tasks, assign bite-sized tasks to the less experienced developers as your judgement advises, create a big picture view for yourself with the best information available of where your team stands with the problem, clarify the picture as you go along, and run interference from the rest of the organization's managers who Manage by Dysfunction.
A side note for younger developers. The only partial shortcut to that unflappability I've had experience with is to secure yourself 2-3 years of living expenses as soon as you can. It helps you achieve perspective, especially when a manager yells you'll lose your job over something. It isn't a replacement for experience, taste, judgement, whatever you want to call it, but it does help a lot with compartmentalizing the emotional component of facing down stressful situations at work, which takes most employees a decade or two to learn, and some don't learn it at all.
Are you sure you are not committing the same ageist judgement here?
The tooling accessible to people today as opposed to those that started 10 years prior is also extremely different. Running Windows? Trumpet Winsock, understanding the win.ini, config.sys, and autoexec.bat were important. Linux - a lot of people have wasted a lot of time getting sound and video drivers (as well as xf86config files) to work right, most just work fine now. All these required a level of digging that required knowing more about the system than you may have wanted.
Not saying your point isn't valid, but it does depend on what one's definition of "competent" is.
One is an active reverse discrimination that is attempting to tilt the balance back (often enforced with some kind of law or policy). This has all kinds of well-known problems (that arguably are larger than the benefits).
The other is a more natural reverse discrimination that comes from collecting the missed opportunities of your competitors. If your competitors reject candidates for frivolous reasons, then it's easier for you to hire qualified people. I think this is what the parent comment was doing, and it doesn't strike me as a problem.
Enders Game is a good allegory for this.
It's good to have diversity and meritocratic process for decision making. It's good to have different perspectives, but recognize that sometimes bad experience is worse than little experience.
What you're saying is that some people don't learn from their experiences. You should focus on finding out if they have. That's worth way more than hoping that this young kid will.
Good developers do use pattern matching. But good developers just use it as a way to come up with ideas, and they use their experience to judge the ideas.
There's no such thing as "bad experience", just poor reasoning skills. And mostly people will improve their reasoning skills over time. Unfortunately, not always.
Prove it with some research. The current research shows that people really don't make their best contributions to their field before 35-45.
And, to be fair, I see more young people who attempt to hit the screw with a hammer because a hammer is the only tool they have.
Look at someone like John Carmack - before he was 35 he had done Command Keen, Wolfenstein 3D, Doom, Quake 1-3. Guys like Steve Wozniak were basically out of the business by the time they hit 35. Linus released Linux when he was 22, and started git when he was 35. I doubt guys like Marc Andreesen have written much code since they hit 35 as well.
So, basically what you're saying is that young people can churn out software where you can undo your huge screwup, but if you have to get it right the first time like hardware, then you need some experience.
You are the one with a "platonic causation", namely, older = rigid thinking.
Enders Game is a child's book, written to appeal to children. Note we don't actually have 9 year olds making decisions in reality.
Theory: This importing of workers has negative effects on age and gender diversity, since it means a higher proportion of jobs go to people who can easily relocate for work. That includes young people (who are less likely to have kids and/or spouses) and men (who more often receive the primary or larger income in a household). I'm sure you can think of other things that are advantages or disadvantages when it comes to moving to California for a job.
There are ways to test whether this effect exists and how large it is. For example, you could compare age and gender diversity across industries. The theory predicts that age/gender imbalance is correlated with geographic concentration of employment growth for each industry. You could also see whether these imbalances are worse within industry hubs, compared to companies in the same industry outside the hubs. (Though the effect can also spread outside the hubs if it influences a culture that gets exported to the rest of the industry.)
I'll bet geographers or sociologists have published research on this subject, though I don't know enough to search for it effectively. (I found some vaguely related papers on Google Scholar, but nothing yet with data that would directly answer these questions.) There are some historical parallels of course, like gold rushes and resource extraction booms that cause new industries to grow suddenly in a particular area.
The need for developers is so strong that all the major tech companies are devoting resources to recruiting as soon as developers graduate.
That dynamic could account for a reasonably large part of the age imbalance in the industry. If there was a similar-sized pipeline of recently-trained developers with a more diverse age group than university students the story would likely be different.
No way a 40 year old guy have more experience than me in general programming, unless he was working at Microsoft or IBM at that date, and surely they are about less than 10000 of those guys in the world. Of course there are 40 year olds that may have way more experience than me in a specific language or technology.
My point is that if computer tech is only 30 year old, then you won't find programmers with more than 30 years of experience, no matter their age.
If you were using one at age 10 and are now 35 that would have been 1989/1990 or so... there were no magazines writing about it by that time. You had some old issues of the TI-99er or something?
There was lots of stuff going on with the DEC minicomputers, LISP machines, early UNIX systems, and big-iron mainframes long before most of us were even born, let alone getting our starts on TI-99s, Apple IIs, and Commodore 64s. And let's not forget that the people who were creating those early home-computer platforms were themselves all from the previous generation.
Would you turn people like Steve Wozniak or Al Alcorn or Ken Williams away from your new startup? You'd be a fool if you did. The basic architecture of computers hasn't changed at all since they did their most important work, and the cognitive skillset that makes a great programmer is the same as it's always been.
In fact, I'd expect that people who cut their teeth on early systems, and had to work within narrow constraints, without a big stack of abstraction layers and frameworks, would be all the more adept at writing robust and efficient code than those who learned on modern tools. And I'd bet, with Moore's law slowing down, and with better-optimized code becoming more advantageous in building scalable systems, older programmers will soon be in higher demand.
I think that it would be a mistake to say that computer science has truly been around for 160 years, though. A few people (there was also an Italian who was interested in Babbage's work, although I'm not sure what his contributions ended up being, if any) does not a field make, and the fact that any progress in it was more or less put on hold until the early 20th century (when mathematicians started working on what you could calculate or construct in a finite number of steps), and you didn't get (untyped) lambda calculus and turing machines until 1936, which is probably the best place to truly start the idea of computer science as a field. (And since you got early devices that were sort of primitive mechanical computers in the late 30s, early 40s as part of the whole Bletchley Park cryptography work by the Brits.)
A very large debate around the turn of the century was if mathematics that you couldn't specifically construct in a finite (or countable) manner were, which became particularly heated after Cantor's set theory work (showing that the real numbers were uncountable) and then things like Russel's paradox (showing contradictions in Cantor's naive set theory if you allowed sets that contained themselves). I'd argue (without firm, researched proof that it was definitely the intent and case) that the spirit of early computer science (lambda calculus, turing machines, etc.), which was concerned with what you could and could not compute with a finite algorithm, came in spirit from those sorts of debates. (See finitism, intuitionism, constructivism, etc. for parts of this debate; traces of it remain in modern day mathematics with some people's concerns about if the Axiom of Choice is a valid or reasonable axiom to have)
ENIAC was ininitially put to work calculating artillery trajectories, once the programmers figured out the bug where the shell kept going after it hit the ground (oops!).
(Not trying to short-change Bartik here either -- she did a lot of the work on the ENIAC instruction set when they converted it to a stored-program computer)
Edit: And many more "giants", of course…
I started programming toys in 1979. [1] I started programming "modern" computers in 1981. I was selling games when I was 15 in 1983. My "real" professional experience started in 1987 with a contract to write a video game from a major publisher.
So yes, it's not hard for someone to have "more experience" than you in general programming.
[1] I had one of these: https://en.wikipedia.org/wiki/Big_Trak
http://www.bigtrakxtr.co.uk/home
Do you know how many people were doing that? you are way over estimating the amount of people in the world with your experience.
You said "No way a 40 year old guy have more experience than me". To disprove an absolute statement you only need one example.
That said, a significant fraction of my friends from those days were doing similar things. I won't deny that I'm particularly good at programming, but all of those friends could also claim more experience than you.
I've heard a number of these comments recently drastically underestimating how long computers have been around.
I'd be really interested as to how you get that figure...
Working in a bank, not for an editor...
FWIW, I'm 47 and was programming assembly and microcode in my youth. So I have 10 years on you. At this scale, I doubt the difference matters much. Because you are old, too.
Also, you have about 30% more experience than me, I don't think it's a small amount.
So it makes little sense to suggest that it's somehow a crazy idea that someone 5-15 years older than you (in their 40s) might have a longer track record working with computers.
> No way a 40 year old guy have more experience than me in general programming, unless he was working at Microsoft or IBM at that date, and surely they are about less than 10000 of those guys in the world.
You're talking about 1989, right? In 1983, there were 443,000 computer programmers and 276,000 "Computer systems analysts, scientists" in the United States alone (source: http://www.census.gov/prod/2/gen/96statab/labor.pdf).
My father got lucky in that he was successful in his transition out of engineering, and was 67 by the time his position went extinct, but there are a whole bunch of folks who would rather have been engineers than otherwise, but ended up missing out on a couple decades where the daily tasks of building software changed dramatically so gained less in technical expertise than they should have, and were left hanging around age 50.
I have a ton of cultural criticisms of the current tech industry, but the one thing that it is absolutely getting right is valuing creation. The damage that could have been caused by the Google/Apple cartel has been limited largely by the startup industry that, for all its faults, has as a crucial belief that the act of building things is valuable, and that people who make things are the ones who create the most value.
That has all changed and yet back then was accepted standards from what I could tell. More a insight into culture change but I have not heard of any agisim culture inside IBM before or now, just a beard thing, which has passed.
With that anybody have any insight as to any agisim aspects inside IBM past or present?
IBM used to invest in it's employees. My advisor was of a generation where if you saved IBM X dollars in terms of research patents, etc, you were well supported as time went on. Additionally, they had a culture of investing in their employees. I don't know when the change happened... I want to say sometime in the mid/late 90s things shifted and have since.
That said, most of the new hires were under 25, and most of the older people had been employees since the age of 25. But definitely the older people got all the respect.
IBM's full time offer to me was a solid 1/2 of Google's offer after stock and bonuses (over 2 years), with no room for negotiation.
What's wrong with that?
We were essentially doing the lose-lose algorithm. It's a functioning hash table but there's a lot of room for improvement.
There was a cultural shift internally when Gerstner was brought in - before then, there was a culture of "join us, and IBM will take care of you". Saving the company in the '80s required giving that mentality up, and it destroyed much of what, in my parents' eyes, made IBM a special place to work.
For development, it's all about having your niche. If your niche is stable, age isn't an issue. If your niche is going away, there's little reason to keep a 50 yr old C cubicle guy to switch to consulting, 50% travel and code the latest flavor. There's just no cruising on your laurels anywhere anymore and the market turns over much more quickly.
My observation of recent layoffs is that it's ageism in that most of the people in these jobs are well into their 50's and some into their 60's. Young is 40, and if you weren't in a critical niche, you were just as likely to go as any.
I remark to folks all the time that you can take someone right out of high school, and have them spend about 2000 hrs learning about "computers" and now they are 'hot shot programmers' that are in demand. 2000 hours is a bit more than a year at 5 hours a day factor in that the math, and intro classes aren't necessary for someone who has both done the degree before and spent some years working in the field, and I suspect that any engineer taking a 6 month sabbatical could be right back to current. And completely current with the wisdom of organizational dynamics, work habits honed by years of what worked and what didn't, that person should be like gold.
The place where I feel sad is when someone says "I've been unemployed and spent the last 6 months sending out resumes and no one will call me because I'm old." Had they instead spent that six months re-tuning old talents, sending out the occasional resume, and building stuff, that seems to get people hired regardless of age.
There are two problems with that logic. The first is if you have only six months of experience doing something your pay is likely to reflect that.
Second, look at it from an employer's perspective. You can hire a twenty year old or a fifty year old. They have the same experience with whatever the latest thing is. The twenty year old has the energy of youth. No wife or children. He may come in hungover occasionally but with enough Red Bull he'll bounce back by noon.
The fifty year old is slowing down. He takes drugs for his blood pressure that make him tired. He has ailing parents and teenagers at home.
Who do you think is going to be more productive? Who's going to put in 16 hour days at crunch time?
You can't play to a young man's strengths if you want to compete with young men when you're over forty. IMO you'd be better off as the last guy who knows COBOL than just like every other mobile programmer with six months of experience except older and slower.
But if you assume work performance based on age, gender, race, religion, or sexual orientation, you will always be doing it wrong.
I could have probably done it, but really only 6-9 hours a day, like you say, would have been actually working on what they were paying me to work on. I'm still not sure how a schedule like that could ever have been considered sustainable for anyone who wants to have any of: a social life, family, or professional development time (going to meetups and such).
And? What is this article about? Do you think it's productive for older guys to cry about age discrimination when they can't find a job? All I'm saying is you play to your strengths when you're looking for a job, no matter what your situation is. And being an older guy with just a handful of years in a brand new technology is playing to your competition's strengths.
Companies that wouldn't hire an older guy as an Android programmer for $35/hr will shell out $300/hr for that same guy to teach an in-house six sigma class for two weeks. So be the six sigma guy. Does it make sense? No. Does that matter? Again, no.
>But if you assume work performance based on age, gender, race, religion, or sexual orientation, you will always be doing it wrong.
That's all very nice and totally irrelevant when you're the one looking for a job instead of the one doing the hiring.
I'm 31 years old, have been doing lots of crunch times of 16 hour days that lasted for weeks and I really hate this expectation and mentality.
I'm more productive than ever, even though I started saying NO to overtime, because fuck you. Yet, I've worked with plenty of beginners and when I say beginners, I'm talking about 5+ years of experience and I have been more productive then all of them, even though they've been more eager than me to work overtime.
The difference has been in the following areas:
1. less experienced engineers when facing a hard problem tend to slap some code in place that barely does what the feature request asks for, without thinking of the implications much, like the potential for accidental errors, or how that code interacts with the business logic already in place, or how that functionality will interact with future features already planned. And so every sprint, every release you end up reworking/rewriting/fixing stuff from previous releases, because a rookie skipped the due diligence and slapped a poorly thought out turd. As a consequence, that's why we have software development methodologies, like Scrum, or whatever agile bullshit is the latest fad, because process is required to get good results with average people.
2. no man can keep focusing for more than 7 hours per day on average. Yes, I've been able to stay "in the zone" for more than 12 hours occasionally, however the average for really good people is no more than 7 hours. The rest of the time is filled with "busy work", like pointless meetings, replying to email, reading HN and staring at the monitor stupidly. If you don't believe me, install RescueTime and marvel at the huge amounts of daily jerking off.
3. Solid work requires a well rested mind. I'm at the top of my game when I sleep well at night and I get great ideas in the periods in which I have a good social life.
4. I learn faster than any 20-something, because I have a solid knowledge base. For example it takes me about 2 weeks to become functional in any programming language, that's because I've already worked in production and played with about a dozen thus far and in regards to paradigms, I've already worked with them all.
> No wife or children.
5. Pity that you view that as a liability. As a father of a 4-year old boy, I can tell you, a child is the greatest motivation you could ever have, which is why I trust people with children at home more than I trust a 20-something that hasn't felt what true responsibility is like.
* bad_user would be based "anywhere outside of Silicon Valley".
* You wouldn't be.
I was right. (bad_user is in Romania, according to his LinkedIn.)
That's not to say it's easy to blow off demands of overtime outside of Silicon Valley either (I've heard horror stories about game companies), but the tech companies that you can do it at seem much more common.
It may simply be founder/executive age. When the CEO has to go coach Little League, he loses any moral high ground he had for saying you can't go play with your kids.
Being able to say NO is not a matter of where you work, but rather one of actually saying NO. It may not work well of course, your managers and peers might not like that, the secret being to not be at the bottom of the chain - as in, you have to be reliable and capable and work on hard enough problems as to not be easily replaceable. If you can prove that you're as good or even better than somebody doing overwork (which is entirely possible because of the reasons I outlined), then nobody will mind, as in the end it's all about the value / artifacts produced, not about the lines of code written and not about the number of hours worked.
And in my oppinion, if you can't produce value while working regular hours, then working overtime won't help anyway. And if you can't produce value with overtime, do you think your boss will keep you hired just because you're a "hard worker"? The market really doesn't care about that and your boss/manager would be an incompetent if he thinks otherwise.
Speaking of market forces, it's a mistery to me how you Sillicon Valley based developers, that live at the horse's mouth so to speak, can't easily switch to jobs that you like in case you're working in environments full of jerks. I mean, even if everybody expects you to work overtime or to do things you don't like, you can always build your own startup for Christ's sake, something that I (being outside of the US) can't easily do.
That's been my experience. Companies will push and push until you say no. After that they may not give you 30% raises every year, but they're not going to fire a productive employee who refuses to put in long hours.
But that's just my personal experience.
On Saturday, of course, things wouldn't go as expected. Many times we were still there at midnight, and he came around asking us to stay for just one more hour so we could help test the latest build. Then there were more problems, so he'd ask us to come in on Sunday. For just a half day.
This happened probably three weekends out of four the first year I was there. It got to the point people were taking Friday off because they figured each hour of vacation was actually worth three hours.
So I came to the realization it was either put my foot down or find another job, so one Friday I went into his office and said "Don't even ask me to come in on a weekend. Ever again." I thought it might cost me my job, but that was the end of it.
This assumption is wrong. They don't have the same experience. Their direct experience (counted as the time they spent hacking with the latest thing) might be exactly the same, but this doesn't translate to the same effective experience / capability. When I was 20, it took me much longer to become productive with any new thing than it is now when I'm 30. A 20-year old with a 6-month experience with a new language would struggle a lot even with basic concepts. A 30 (or better 40) year old, who already knows 10 other languages and a ton of frameworks would pick it up in single days or weeks and became productive very fast, leaving him much more time to dig into the advanced concepts.
When I was about 18 years old, I struggled hard with a math proof related to number theory a teacher gave me. I never solved it then when I was at school and soon moved on to some other things. Recently, when on vacation I recalled that puzzle and started thinking about it just for fun. I solved it in a few minutes by just drawing with a stick on the sand. I never studied theoretical maths nor dealt with it professionally, so I had no direct experience in doing math proofs. Somehow, my capability now is much better than it was 10 years ago. I call it "indirect experience".
Edit: Am I being downvoted because I'm wrong or because you just don't like what I have to say? Both are wrong reasons to downvote, but you go, you go downvote. My comment is reality. It may not be what you want to hear, but it isn't a low quality comment. I'm so tired of this silly site and it's potato filled echo chamber.
Someone who is continuously improving, while remaining aware of the current environment, will have experience as an asset.
Edit to your edit: You have much to learn...That's reality. Don't worry, I also have much to learn ;-)
Also I didn't understand half of what you said.
You also have to learn when the things you learned before do apply. This is important because technology is cyclic. There are a constant stream of fads that many of the less experienced engineers won't be able to see alternatives to.
- Writing reliable, maintainable and testable code
- Strategies for solving problems that are very large or very difficult
- The ability to interact well with developers, product managers, executives, customers, etc.
- Knowledge of algorithms and other fundamental things in computer science
Being a good software developer is about a lot more than just dealing with the mechanics of the particular software environment you happen to be using today.
The answers change as the landscape evolves, but know which questions to ask...
See? I can be edgy and abrasive too, with equal amounts of validity in your comment as in my summary of it.
Things rarely go obsolete for one thing. Try explaining why COBAL, FORTRAN, VB6, ColdFusion, or hell more modern stuff like J2EE are still around and in good usage. Things become unpopular, often for good reason, but they don't go obsolete for well over a decade. When something costs over a million dollars to construct and its working OK then theres no reason to get rid of it. Most places can't afford multi million rebuilds because its become unfashionable.
What you also learn as you get older is most modern advances are just rehashes (often poorly as they where written over a month instead of years in a research lab) of existing ideas. Or they are nothing more than a load of premade scripts which are nice (and I'm very thankful for the ones I've used) but if you work with clients or existing stacks those often become problematic.
The new ideas that stick often take 5 years to get rolling, and another 5-10 before they sunset. I wouldn't call that quick by any stretch of the imagination. The hype moves fast... but the technology doesn't.
So separate yourself from the hype and you'll see a world moving a lot slower than you think, the given time the overwhelming torrent of new ideas starts to become a same old shit, different day scenario.
This sentiment will bite you in the ass.
I'm sure you can see how this line of thinking leads to a total logical breakdown. The issue I think you are trying to illustrate oh-so-ineloquently is that a lot of developers ossify into "what they know". Then you end up in the "I have this one hammer and everything looks like a nail" issue that is actually real. Keeping up with current trends, tools and design patterns is definitely harder as you get older, but also one of the interesting parts of the job. For those who can't or won't adapt and learn, I'm sure there will be plenty of J2EE apps to maintain over the next few decades just like there are still Cobol apps to maintain now.
If you are routinely running into these issues, the problem isn't with the experience of your peer group, it's with their quality.
Using tables lets me put things on the page just where the heck I want them. I don't know of any easier way with HTML or CSS, and I'm not going to write any JavaScript -- won't do that. Having all my pages just 800 pixels wide is just what I want for my view of a good UI/UX for my Web site. And the Web pages should look okay on everything with a Web browser right up to date as of, say, five years ago. So, I'm not going to test my pages on several versions of each of several Web browsers on each of several devices and, with such simple Web pages likely don't have to. And I have no pop ups, pull downs, roll overs, or anything else that has the screen change just do to mouse movements or anything else except deliberate user actions.
That's the way I want the pages to be at least for now.
That statement right there is the reason tables are a terrible idea for layout.
We have a massive age range all the way from 20 to 60 (I guess), with most of the better engineers in their 30s-40s it seems, though to be honest you wouldn't really know unless you asked - there are guys here that you wouldn't guess were 40.
Personally I know I'm a far better engineer now in my mid-30s than I was in my 20s and to be honest I STILL feel like a beginner excited to finally find his feet. I don't see this stopping anytime soon. I don't want to get into management and luckily don't have to and I'm sure at 45 I'll be a far better software engineer than I am now (well, I sure hope so at least :) ).
The people in SF/SV building apps are mostly in their 20s-30s.
The people building cool technology are mostly in their 40s-50s.
I know 20 year olds making brain wave analysis breakthroughs and 50 year olds making poker apps. And the reverse.
Great work knows no age.
And there's not enough of it to go around.
|The authors examined the high points of the careers of both great inventors and Nobel-Prize winning scientists, and they found that the late 30s were the sweet spot for strokes of genius
The gist is that this number (38ish) has been slowly creeping up over the past century; it is generally higher in those fields which require a synthesis of huge amounts of knowledge (experimentalists) and earlier among theorists. Notice that essentially no one has done anything groundbreaking in their 50s (yet).
What has happened is that most of the bad developers that I worked with 20 years ago are working in banks or outside of development, because it's much easier to hide your incompetence in our 20s than in your 40s.
Now, Silicon Valley is full of fresh meat, and of companies whose best asset is having a guy that is fluent in venturespeak, so I am sure the experience is very different. Just like it's harder to find a .NET job in Seattle if you haven't worked at Microsoft before, given how many former Microsoft employees are available to compete with you.
I moved on to another company and trippled my salary in the private sector, though again was told by the recruiter if I was over 21 I would of got paid at least £2k more than I was.
After a short time I moved into contracting at around the age of 19, doing COBOL work. Again I had many issues due to ageisim for being so young in what was a old generation feild. Interviews would be a complete grilling of which I excelled and shone above and with that got the work. Age was still a factor then and as a young contractor I was often dismissed by people soley due to my age. Though would always shine above them in technical ability, because I had too.
After a few years contracting and the isolation of being a contractor amongst permies(permenant staff) I would feel left out and moved back into permenant work.
Times changed, now it is the reverse and sadly I missed both boats, being at the age of 47 and with the IT feild often shafted on many managerial levels I somewhat regret not working in a building trade as many people I know did and made better money, more free time, less stress and burden. Not forgetting it is a older trade and with that TAX wise more adapt in NI contributions (National Insurance - UK thing) being a pitance on contract to IT, which is full rate. Then there was the introduction of IR35 desigend to penalise contractors in IT directly.
It still is finding it's feet and whilst law and accounts have there long standing estabilished exams of recognition, IT still does not. With any certification easily expiring in a few years and nothing holding up for a lifetimes of work.
Sadly that still prevails and IT is often the butt of all departments in many a company and often shat upon, little reward for good work that saves money over other departments who add little value.
But during my time, one event stuck out. I went for a permenant job at a company - PC Database work, Dataease and turned up at reception ontime. Was left waiting for 30 minutes then handed a form to fill out, which was basicly a HR form regergitating what was already on my CV. I then had an intervew with the HR manager. She was very curt and rude and said, that is a lot of money for somebody your age and was very dismissive and really put me off the company. I had the IT department intervew with a manager and contractor they had in who was an `expert` in the feild. Shone thru and even educated the contractor about a hidden debug mode, happily answeared the question about post codes in so much detail that it was scary (post codes same as USA ZIP codes). This resulted in a job offer before I even got home, offering me more than I was (the recruiter) asked for. I turned it down flat for a lesser paid role as the HR experience had put me off completely from that company.
So whilst agisim is a problem, that problem has gone from looking down upon young people, to looking down upon older people.
But the real issue of IT and one that will carry on for many years is one of establishment, be it certification and exams that stand the test of time akin to accountants or lawyers. Until that day, IT will always in many companies be the shat feild for many due to upper managment mentality. Which ironicly enough is the older people mostly. Younger managerment (CEO's etc) have more respect for IT and also sadly less respect for older people in IT.
With that I often wished I was born earlier or later instead of catching the shit-tide from both ends from when I was young and now older.
Take two 50 year old engineers. The one who has had 10 jobs over the past 25 years is considered infinitely more employable than the one with 25 years at the same department of the same company.
This case isn't ageism, it's the expectation of career stagnation, yet many of those engineers with that 25 year tenure think it is. It's a leftover from the days when loyalty was tied to tenure, and loyalty was valued highly in the hiring criteria. Those days are over. Loyalty is nice, but loyalty that negatively impacts your career options (no learning or improving, inability to use marketable tech skills, etc) is foolish.
When you say 'people like me', keep in mind that just because you have had three different roles at one company in itself doesn't mean you didn't stagnate, just as the person with ten jobs may have stagnated.
All assumptions have some danger, and I'm not condoning the behavior. I think it's valuable to explain to people who feel they are being discriminated against based on age may be more likely associated with stagnation (actual or assumed) based on extended tenure.
I'm certainly not saying that someone who has held multiple positions has not stagnated, either, simply that fundamentally the only difference between me and someone who worked for three different companies but had the same roles as I did is merely the company nameplate. To make different assumptions based solely on that is illogical.
Are you arguing that in that scenario it's more likely that the one-workplace worker really has better experience, or are you arguing that it's possible that he has better experience?
CV-sorting is not a maximization problem, it's a satisficing problem of getting a few good candidates to the interviews at a reasonable cost; which generally requires throwing out 90% of CVs without spending the resources to seriously investigate those people. As long as you have enough qualified candidates, factors that "often are bad, but sometimes are good" equal an automatic forward to the circular folder under HR desk.
Older technologists are out there, but they're a bit nomadic.
There are still some colleagues my age who still wax about the days of writing JCL for their mainframe jobs and never evolved past the 80's and perhaps they gave a bad name for others who built on their of years of experience with evolving knowledge.
I decided in 2009 to specialize in mobile, when I realized how impossible it was for the startup I was working for to find any high throughput engineers, let alone high throughput engineers with niche expertise in mobile. I think it is an advantage in some ways during interviews that I can talk about decades of awesome projects I worked on while also being among the first to ship an iPhone app or a top ranking iPad app.
As they say, luck is when preparation meets opportunity. It's my job to make myself lucky.
I also think I wrote kind of silly code then. I always laugh when I think about a persistent hash table I had to write and how I went out of my way to find prime numbers for M slots using Fermat's Simple Theorem (not his last theorem) and testing for Carmichael numbers. Of course, there aren't that many prime numbers in the first place and a static table would have worked just fine! I always remember this as part of my evolution from an inexperienced academic kid solving a problem that doesn't need solving vs. experience to know where to comprimise and just get it done.
Even then, I knew it was important to start specializing where the needs were evolving, which was win32 programming at the time and eventually Windows MFC programming. This all dove-tailed nicely years later when I started working on the Playstation 3, where you develop in MS DevStudio but the PS3 was essentially a Unix box. It's funny how things work out.
The only thing that sucks about being a 40+ engineer is when I say "whachoo talkin' bout Willis" or "it's tricky to rock a rhyme", half the people don't know what I'm talking about.
There's your problem. You have to ask it as a question.
Try telling someone they're "2 legit 2 quit"; the kids today are not sure if that's good or bad.
Interesting! Was it ageism or was it because you were inexperienced? This is tricky because I feel like even if younger developers are discriminated against based on their age, they might be less likely to attribute it to ageism. If this is true then I wonder if older developers are for some reason more likely to blame ageism for their career ills instead of skill obsolescence, hence making ageism seem like something that mostly affects the older devs...
We're just figuring out where the old abstractions land and the syntactic sugar has made life easier.
There is a massive personality issue at play. If you love this stuff, you don't let new stuff pass you by and end up being a specialist on the dead end. You're constantly sharpening the sword... because you love sharpening swords. Staying relevant and employable is a side-effect.
As I get older, I find that is easier said than done. I still spend quite a lot of time learning new things, but I've become less interested in learning things that are immediately marketable. Learning yet another framework that is marginally different than the one I used on the last project is not the interesting pursuit it once was. At this point I would rather invest that time in something that might fundamentally change my outlook and understanding of the world, which is beneficial in a meta way, but isn't really something that you can specifically write down on a resume.
I find the older I get, the slower I produce code. I spend more time thinking about the solution than coding the solution. This tends to frustrate my employers, who follow the "move fast and break things" philosophy. They think I shouldn't have to think about it, just do it.
So, I guess what I'm asking is, in your opinion, is my slowing down a problem? Or an advantage?
Freelancing might suite someone like you very well though. The best freelancers write solid software at the pace that works for them.
sorry, what? any team that thinks "rapid development" actually means writing code more quickly is a team composed of idiots - I think I must be misunderstanding you?
If it's incurring a similar bug load and just gets done slower, that's a problem and they're right to be upset.
I've seen both cases before, even from very experienced people, so it's very specific to the situation.
Agreed! as discussed here: https://news.ycombinator.com/item?id=7452643
The narrowest experience is actually amongst the mid/late 20 somethings in our group. I'm not sure if it is that lack of systems experience, not much exposure to C and lower level languages, or what, but they need more mentoring than what I recall needing at the same age.
I'm currently doing that for a couple of them and it is actually both challenging and interesting. Challenging mainly in how to convey tasks, teach them troubleshooting (without the hand holding), and a few other items. Interesting because we all learn differently and seeing how others approach problems either reminds me of my own trials or forces me to think out of the box on how to explain things.
Personally, I've always been a bit of a control freak when it comes to development -- I want to know system level through whatever level I am developing at. This often includes system administration, database management, etc. This has become much more challenging as new technologies come about -- so in those cases, say NoSQL, I will focus on one or two solutions rather than trying to understand each. Build a basis for the concepts, where it is useful, and then test, collect data and reevaluate.
There are red flags that you can easily spot in a job interview or job posting that indicate that the employer wants 80-hour weeks. And who signs up for 80-hour weeks? Naive young people who don't value their time and don't have other commitments, like side projects or family.
It's easier to gauge over the phone or in person. It's often the way things are said that act as a trigger. If a founder works 60-80 hour weeks, it's going to be expected that you will too.
Given the increasingly insane economics of the Bay Area they're attaching millstones around the necks of the companies they invest in. And just like with ageism the purported benefits on which they base their biases are dubious at best.
Pushing 50 and it frickin' works for me...