Old Techies Never Die; They Just Can’t Get Hired as an Industry Moves On (2012)
nytimes.com
nytimes.com
For my own part, this is still what I love to do. I'm busy 10 or more hours a day and at least eight of them are spent with some technology I knew nothing about six months ago. I was layed off from another startup at the end of September and started this current gig three weeks later. We just finished five weeks ramping up on Google Container Engine, during which time I also learned to use GNU make for the first time, and learned about etcd and Google Compute Engine. What it boils down to is this: stay interested, and stay current, and you stay employed. If those things are not within your power you no longer belong in this craft.
I am not quite as old (45) and I still love learning new things, but it does take more effort than when I was younger.
Absolutely true, and it's also fair to say that I have to work harder now to remember things that I could recall effortlessly twenty years ago. Fortunately the development of the Internet into a global knowledge store perfectly coincided with my getting older :). I know most developers couldn't work without the Internet these days, and that's doubly true for me!
I still remember trying to write assembler back then by memory poking to speed up the inner loops of my BASIC programs. The crazy thing is occasionally I would get it to work despite having (almost) no idea what I was doing.
But there are 100 javascript frameworks that all do the same thing! After a few years you will stop being motivated to re-learn re-inventing the wheel too. But all the jobs expect you to know whatever's hot right now. That's not engineering, it's fashion.
If you notice, a lot of these people in that article are in hardware design: electrical engineering, probably Verilog and the like. A lot of that work has successfully been outsourced which I think is the real cause of the decline. I suspect it didn't look like it was a particularly bad field to be in until it suddenly wasn't.
It's a long way from webdev though. And yeah these are presumably smart guys who could pick up webdev, but could they make the career transition without getting bumped back down to Junior by the hiring manager? And who wants to hire a 45 year old junior web developer?
There was an article recently about YCombinator shifting its investments to biotech. Suppose webdev dried up and all the funding started flowing to biotech. I'm sure I could learn what I'd need to know and I bet you could too, but could we head over to the biotech companies and sell ourselves as "middle aged web guys, self taught biotech engineers (no experience)?"
Having said this don’t worry, if you think the job prospects are bad for old developers they are far worse for old scientists.
If you look at current jobs such as "bioinformatics programmer", the salaries are somewhere between a biologist and a software engineer even though it requires more knowledge than either. Remember, biologists start off at around 35-50k/yr on jr. level, while SEs start at ~100k+.
Basically, it is better to be a junior level SE than a super senior bioinformatician.
The real problem with biology is the salaries don’t rise as fast you become more more senior. Biotech is certainly not the easy way to wealth.
One reason I am glad I got out of biotech.
Anyways, thanks for sharing.
It doesn't usually require more knowledge. The majority of bioinformaticians that I know are pretty poor coders, and know just enough Perl or Python to count some stuff up an do some stats on it or plot a graph. They have no idea how to set up a server, write maintanable code, design a database well or keep a website secure. Obviosuly there are exceptions, but the majority that I have worked with are junior level programmers with knowledge of biology.
I am not sure you fully appreciate what " knowledge of biology" means. As a programmer who did a lot of molecular biology in the past - doing molecular biology is not simple. The learning curve for a lot of biological topics - especially the ones that get close to organic chemistry is really steep.
Programmers underestimating the value/knowledge of accountants/lawyers.
Businessman assuming tech work is simple.
People by default assume what looks simple for someone to do must be simple - even if they spent 10,000+ hours practicing it.
A lot of bioinformatics is implementing elaborate algorithms in a memory efficient way.
Things like
- approximate string search using modified suffix trees
- some new variation of the EM algo using a new optimization strategy
- the whole protein folding field where many implement the simulations on a huge array of GPUs. Here you not only have to know how to write efficient code on GPUs, but also be an expert in parallel algorithms if the algorithm you are implementing is not embarrassingly parallel.
However, these algos will be thrown out in a month so they don't care about maintainability or uptime.
Of course with 20 years of development experience and 5 years of teaching experience, I had a lot of other things to sell as well. I certainly had no lack of interest and had positions to choose from. I did take a fairly healthy cut in salary, which seemed reasonable to me since the company that hired me was taking a risk. I was careful to pick a position that would work well for me and I did not take the highest offer. I definitely feel that the investment I made at the beginning was definitely worth it.
I think as an older person moving into a different area you have to be able to convince people that you will pick things up quickly and that your other attributes are worth it while they wait for your technical skills to come up to par. If you are careful to build the kinds of skills that will be valuable throughout your career, you will have relatively no problem in my experience. The people who have trouble are the ones that were just scraping by in their original positions, or people who had a laser focus on a particular skill set that is no longer valuable.
This begs the question: how did you manage to get those interviews?
If anyone looks at the code, it's pretty crap, but it shows that I like to write code.
Also, because I knew I was going back into IT, I built: http://mikekchar.github.io/portfolio/
It contains a bunch of egotistical musings about software. It shows that I probably think too highly of myself, but that I know how to write English fairly well ;-)
Also, after I moved to London, I made a point of attending events where I could make contacts. My return to IT was complicated by the fact that most of my career was in Ottawa, Canada. Since my family was moving to the UK, my contacts were useless to me. I got 3 interviews in as many weeks from simply meeting people at the pub.
As far as I'm concerned, these activities are "selling myself". The fact that I also enjoy them is beside the point (especially drinking beer and chatting with other developers ;-) ).
Lately I've been working on trying to allocate time to my side projects. As you can see, I haven't updated my previous projects in a very long time. However, it is vitally important.
In the end, the job I ended up accepting was through a head hunter. No idea how he got my name. Probably should have asked him ;-).
That sounds pretty awesome, actually. Who wouldn't want to add that wealth of experience to their web repo?
That smacks of pure ageism to me. Just recast it to a racial context to see:
"And who wants to hire a black junior web developer?"
On the other hand I often feel like the bar for keeping up can be extremely low ... at work I am back to using Unix-derived systems after some 30 years. And emacs, again 30+ years. And C++, over 20 years. You get the picture.
I usually have to resort to my own projects to learn something really different.
My latest example of this was learning Scala 5 years ago. Bet on something new, and then you get calls from all over the country to work on it, as most people are trying it, but few know what they are actually doing.
Beyond that, language/technology specific Meetups, mailing lists, github repos, and even IRC are a great way to be noticed.
The last thing is that, especially for a new or niche specific technology, it really helps to be in one of the tech hub cities. Remote work is often available however it requires more self promotion (IMO) than being on site.
As a young dev, I really want to learn how to do this. I'm a newcomer to the Scala party, but I can definitely see it becoming a huge player and there are so many reasons - Odersky has basically a team of PhDs at EPFL constantly making awesome stuff for the language and they have made some incredible stuff - TASTY + scala-meta is one of the latest, Scala.JS is another, and really the list goes on and on.
But I'm only beginning to clue in on this now. Would've been great if I had jumped in earlier. If you don't mind me asking, how do you learn to pick the right horse? What were the signals for Scala? my guess now is the fact that Odersky was a major contributor to Java and built both a strong technical team and corporate backing, but thats hindsight ofcourse :)
Managers don't seem to make more either, so it seems you have to be specialized and have a really impeccable resume (and that doesn't mean having Microsoft and Apple and Facebook on it.)
I guess it's for the better. Flipping burgers is probably in my future, and I am pretty happy with it.
It means that anyone can learn a programming language and become as 'competent' as the 55 years old. When you have a choice between a 22 year old and a 55 year old, equally competent, who of the two is a better bet ?
1. save time
2. save money
3. make money
No rational employer will look at a time saving, money saving, money making candidate and think "this person appears to be too good a match for my business needs".
Business value trumps ageism. Most the candidates I couldn't place typically didn't focus on trying to be profitable employees.
I vividly remember a manager (50-ish himself at the time) screening resumes once, letting out an exasperated sigh at the sight of one: "this one was born in the 60's, jeez!". I was the ideal age for a programmer at the time so it didn't affect me, but it still shocked me.
(I know it's customary not to include a date of birth on an American resume, but they'll still figure it out from dates on your diplomas, work experience etc)
It can always be daunting when new tech comes out and hard to be a newcomer in an area you have so much experience in, better to embrace and learn or consider another line, as apposed to be a grumpy ol' stubborn git ;`P
Yeah, but should they be tossed aside for that? And should everybody be expected to keep up against fresh-out-of college people?
Maybe the speed of technology change can be a problem, especially if it starts putting out of a job more people than it employees, and no counter-measures (e.g. citizen's income, etc) are in place.
Not to mention that a lot of this "technology change" is just changes in fads, and there were perfectly good technologies 20 and 30 years ago that are even better than the latest BS du jour at what we do now. Just ask pjmlp!
Of the companies I went onsite to, half of them gave me offers. The others didn't, but not because of ageism but because my interview performance wasn't as strong as I hoped (asking questions in areas I wasn't prepared for, lack of expertise in their desired programming lang, screwed up the coding question, etc). All of the offers I received were an increase from my current job.
Overall I would say that ageism doesn't exist. Employers want people that can contribute quickly without a lot of handholding and without training. This applies whether or not you are a fresh grad or a veteran programmer. If you instill confidence that you are highly qualified to the interviewer, you will generally get the job.
And as someone who has been intimately involved in the hiring process as a hiring manager, I can say the same thing. I've interviewed people of a variety of ages and the only takeaway I care about is will they hit the ground running and contribute to the team quickly. That's why software developers are highly paid. When I first started working, IBM would give aptitude tests completely unrelated to programming, and if you did well, you would get a job and be trained.
Unfortunately those days don't exist anymore, for the most part. It's a problem caused strictly because of how highly paid engineers are. If salaries were 50-60k, then I'm pretty sure companies would be more apt to training and waiting for new people to get on board. But salaries are easily 3X that in the Valley, so at that price, you need to be contributing very quickly otherwise you're a waste of money.
I turn 68 next month. 7 years ago I was cold-call recruited (they called, not me) and offered by three companies all wanting embedded systems expertise. All at the same time. Never rains but it pours, eh?
Two were boring embedded Linux. One was fun gaming console OS. Audio SDK and DSP, specifically (although I was not pointed there for a good year after hiring). I'm still there. And the interesting bit is - I had never coded Audio or DSP before. They liked my technology surfing history, that wide 'T' shaped profile on LI. And, clearly, age had nothing to do with it. Experience, proven adaptability, and quick at learning new stuff did. Is my theory, anyway. But that is not something one can decide to add to the CV in a panic after the fact of layoffs. It starts in ones' teens and never stops.
But then, this is an established Japanese company in Seattle. Two major differences to SV start-ups.
My impression is that the industry is changing... not really in the tools we use (UNIX is older than I am; we keep re-hashing some combination of C and lisp, it seems that virtualization tech is on a one decade cycle. It's the same shit, new packaging) - no, the industry is changing because more "normal people" are entering it. Standards are going up in terms of expectations of things like social skills, being tall, good looking, etc, etc, all the things you'd expect to need to succeed in sales or management or other things that a normal person might do. My observation of my unemployed friends; the sort of people who were seriously into computers in the early to mid '90s, is that they are generally rejected on "cultural fit" grounds. "You aren't cool enough to work here"
I mean, it's still way easier in tech than in sales, for a person with poor social skills or poor confidence, a man who is short, or someone who is plain ugly, but every year, the vast difference between sales and engineering seems to be shrinking. It's pretty dramatic, really, because when I started in the '90s, it seemed like this was the haven for people who were not welcome anywhere else. Being smart enough to do the job excused a lot of negative attributes that would not have been excusable in other fields.
Couple that with the following realization: the folks in pure product innovation roles at startups -- the people who are supposed to be insightful oracles creating compelling visions and perfect shortlists of vital user stories for killer apps -- these people are not ... really ... that ... good. (Even the ones from Stanford.)
So, now programmers must define the product, create the product AND sell the product (with their cool, unshaven, youthful faces).
All programmers must now be brogrammers. The pure nerd work is sent overseas.
This is with bay area startups. Outside the bay area I can't say... but because I'm not in the bay area and all interaction with them was remote I can say there was a comparison to be made.
It's the dipthong startups that are the problem-- these kids these days don't know nothing about technology and believed Mark Zuckerberg on the Startup School stage in 2007 when he said "Don't hire anyone over 30 years old! Young people just get it." (paraphrasing, but I was there, it was obvious he had no understanding of the concept of wisdom.)
Anyway, discrimination means you miss out on the best people-- and at least according to my employers, they're pretty grateful to have me.
But pebble, digital ocean, and the like... they can't see past the grey beard.
"Old Techies Never Die; They Just Can't Get Hired in Bay Area Technology Companies and Startups as an Industry Moves On."
"The average and median age of U.S.-born tech founders was thirty-nine when they started their companies. Twice as many were older than fifty as were younger than twenty-five."
Cites: https://smallbusiness.yahoo.com/advisor/older-entrepreneurs-... ; http://www.kauffman.org/what-we-do/research/2009/04/educatio...
Lots of old people start companies, but the key to success is having a wide variety of experience, and not being afraid to get more (like sales! like marketing! and so on!).
You can do it! (I did! And just landed my 4th customer for a high-dollar-value subscription service!)
My advice to all of you - young or old - is never forget to learn new things. Always have at least 5% of your stack of things, to do with learning something new. Software development is not a 'career': its an art form. There will always be new states of the art, and as an evolving process, will necessarily involve abandoning the old and continuing with the new.
Nobody cares if you're old. Everybody cares if you've been doing it for 30 years and still can't write a parser, or compile a new library, or spend 8 hours to hack up some code in a new language that nobody knows about yet. Keep that stuff up, newbies and old-folks alike .. its the only way forward.
I think that the current complaints about age-discrimination, apparent and false though they may be, indicate a misguided but passing phase that the industry is going through. People are hedging with trivial ideas and products, hoping they will stick. These guys built a CAD product on the cloud called Onshape, check out their engineering team - https://www.onshape.com/team
There is this sense that many problems are unique to one industry when they are shared across many.
The language itself is actually pretty cool. I enjoyed working in it and learning legacy stuff; it made me appreciate what we do have now.
The work of maintenance on old systems is just annoying and boring. That's all you generally do. Few people are rolling out new things in COBOL even on older systems. It's just maintenance, debugging, and providing support for new features when the domain you are working on requires it.
I have high hopes for Ruby on Rails -- it won't have the longevity of COBOL, but it's gonna be a nightmare of a legacy system ;-)
It's a tricky career path but if you just want to count down the clock on your career and build up cash for early retirement it does have it's benefits.
I'm an expert-level python, web, and javascript dev, with wide experience in admin and QA as well. In my 40s, up to date, and a much better developer than I was a decade ago.
This wasn't much of a conscious choice, it was just the way it panned out for me early on but after 21 years in IT and only 1.5 years of that in 'permanent' employment, I feel glad that this way of working has forced me to chop and change roles, technologies and sectors so that I have done UNIX/Linux SA, DBA and storage work and have had some recent AWS/ansible experience too.
If I had stayed at my first 'enterprise' role, I could probably be in some management role now or be in a technical role that would have made me hard to employ elsewhere too. I'm much happier that I think I now have a record of varied experience showing I can pick up new stuff.
Languages, tools, and frameworks evolve (including the brand new distributed programming language I invented, 'Hello', available at http://www.amsdec.com/).
But good software architecture and engineering is an art that improves with time.
Amazeballs wasn't even invented until 2014. we all know that.
stupid recruiters.
But on the hardware aspect, I would think there is hope. Given the increasing move towards the new maker mode of desktop fabrication & IoT, there should be demand for people with hardware skill sets that integrate well with web, cloud & mobile.
The problem always remains that the smartest minds are frequently poor at marketing themselves.
1. Market yourself so that when you hit the pay ceiling, you can move into consulting/freelancing with enough of a name for yourself that you can justify your rates to businesses.
2. Move into management. If you hate marketing, start looking for management/mentoring opportunities now so that your next promotion/job has some sort of manager title, which will continue your mobility up to the Director -> VP -> C-level.
EDIT: 32. Didn't save enough in my 20s. Saving as much as I can now (living below my means, paid off my mortgage, maxing out 401K/HSA/IRAs).
I'm at year 32 of not blowing it. Although I've lost more to inflation and low returns than I've spent.
if you run your own biz, you work for someone - your customers. and you need a steady supply of those, which looks easy at the beginning, but a couple years in can get really, really hard as they retire and you suck at sales.
seen this so often not even funny, forced early retirement on shitty terms due to a tanking self-employement biz.
You do have a little more control over the situation than you do if you get laid off for turning 40.
Obviously these fields move slower than tech but would be fascinating to see what could be put together to broadly engage and keep technical people (self included) on their toes.
Mix the curriculum between the applied (new languages / dbs / OS), emerging market exposure (vr / crypto currency / self driving), and the novel (snapchat / vine / etc).
"stay on the cutting edge".
Ha! The real leading edge is work that is at least "new, correct, and significant" and published in a peer-reviewed journal of original research in information technology, yes, and also powerful and valuable in practice.
So, put on resume that have published in original mathematical statistics for detecting zero-day problems, in artificial intelligence, and in optimization, and still get silence. With Silicon Valley, leading edge has no connection with peer-reviewed original research!
So, do a startup. Web development? Taught myself -- the Web page code works fine. The difficulty was a lot of poorly written documentaiton. The software was fast, fun, and easy.
"Leading edge"? Yup -- my startup is based on some original applied math I derived, complete with theorems and proofs. Likely and apparently I'm the only person in the world who understands that work. Definitely leading.
The problem my work solves, a lot of people have regarded as important. So far, I have the only good solution. Some of the people trying to solve the problem say that the solution I have is impossible -- they didn't understand what the heck they were talking about. They couldn't come up with a counterexample why not or a theorem of why can. The people just were not very good.
Problem is, really, leading is not what Silicon Valley is looking for. They wouldn't know the real stuff about leading if it slapped them in the face. My best published papers, nearly no one in Silicon Valley has the prerequisites to read, and likely no one outside of Stanford or Berkeley and only a few people there.
Instead of leading, they want two years of experience in just what the heck low grade, routine, simple minded, poorly documented API or OSS they are struggling with today.
Those people are being self-taught on their way to the leading edge and are floundering around and stand not to get to the leading edge. E.g., they keep saying Bayesian and power law but don't know the difference between the weak and strong laws of large numbers or about conditional expectation, non-parametric hypothesis tests, the Radon-Nikodym theorem, anything about martingales, the Neyman-Pearson lemma, etc., enough about conditioning even to understand the definition of a Markov process, a basic result such as
E[E[Y|X]] = E[Y]
the role of sigma algebras, or any such things.
Early in my career, I started in computing and started to get self-taught in the often associated applied math. I made good progress in some things but otherwise floundered around with low quality materials, etc.
Then I went for a good Ph.D. and got one. Now I can say, nearly no one in Silicon Valley startups is in any significant sense even near the leading edge and, instead, they are just floundering around.
Back to my startup -- a few good days and I should be able to go live.
Read back on your posts a few pages, respectfully requesting to be put on your alpha list as well. My email address is on my profile here, for the time being.
i.e. the definition of probability? yea, i expected ppl to be more interested in that, myself
otoh, be careful about minimizing other skill sets. doesn't take much more than basic arithmetic on the math side to understand the linux kernel, but the skills needed to be productive with such an engineering challenge aren't any kind of joke.
> Linux kernel
Difficult? Right. No doubt by now it's huge, and I have to believe has many patches. And I have to suspect that it's not well documented. And people that use it especially want it for high end work where they make modifications, and then the problems of complexity, documentation, testing, etc. get much worse.
Difficult? Yes. Leading edge, not in the usual sense of knowledge. More broadly, tough to make progress in any sense if still have to spend much effort with the Linux kernel -- we're supposed to be past that by now. This may be wrong for some niche need, but people should try to keep their careers out of such niches.
Linux kernel performance? Might want some math there!
Instead, often want the real stuff. For that, usually need a good version of the math prerequisites or will struggle.
Where I had good prerequisites, I did fine. Otherwise I struggled.
The graduate work that did me the most good was some quite serious work in optimization, measure theory, functional analysis, probability theory, and stochastic processes.
So, then, presto, bingo, look at Fourier theory, L^1, L^2, etc. and prefer it to the best ice cream and cake. Gorgeous. Powerful. Great fun -- and I understand it. Before the grad studies, I was never quite sure what the heck had a Fourier transform and what didn't, when I could interchange order of integration, etc. It was like driving a car but not knowing how many wheels it had. At one point I got pushed hard into the fast Fourier transform, and taken narrowly that was okay, but the narrow view is not the one really want, and I had to struggle with the broader view. E.g., if have the power spectrum of the noise and that of the signal, what filter do you want? Generally if do know what linear filter want, then can use the FFT to implement it. At one point it would have been good to have done such things, but I didn't know how. Now I'm sure I could read it, likely from N. Weiner and then from more recent sources and find it easy reading and/or just derive it myself.
Just why is the power spectrum the Fourier transform of the auto-covariance or some such result? Then I didn't quite have the background for that; now I'm tempted just to derive it myself.
Ergodic theory? It was also great fun. Before the grad school work, ergodic was just a mystery.
Now I can browse and thoroughly understand and enjoy Luenberger, Optimization by Vector Space Techniques, e.g., Kalman filtering, deterministic optimal control, high end versions of Lagrange multipliers. A lot of it is based on the Hahn-Banach theorem, and I saw a rock solid version of that. Before grad school, Luenberger would have been a bit much -- I would have struggled, often not quite sure just what I was doing, limited to some painting by the numbers.
Before grad school, at times I wanted to know Kalman filtering and deterministic optimal control but struggled. It would have helped for me to have known those topics.
I wrote my dissertation in stochastic optimal control, but I wished I'd been able to have a good, high end course in such things, including with stochastic differential equations, etc., but there wasn't much in courses to pick from. The number of US departments that know and teach that stuff is tiny. Off and on I considered just some independent reading courses for that material, but various exogenous events caused me to run short on time and cash and rush to finish instead.
Before the grad work, I found statistics to be a cookbook of bad tasting meals.
Now the usual statistics books bore me; I don't know of a really good statistics book; and I usually end up just deriving what I need for myself. With a good background in probability, that's the way to go.
I had a pretty good undergrad major in math, and when that was enough as prerequisites I did well. E.g., I touched on linear algebra as an ugrad but wanted more. So, I got a stack of books on LA and dug in. Of course, the best was Halmos, Finite Dimensional Vector Spaces, but that didn't cover everything closely related, e.g., applications to calculus of several variables, numerical linear algebra, connections with multi-variate statistics, etc., and I got books on those for more.
My ugrad work didn't do really well with multi-variable calculus -- no wonder because too soon really need measure theory. So, I got partly caught up on such calculus on my own and got a lot more in grad school, but I still don't know differential geometry well enough to find general relativity easy and wish I did. At least now I have the prerequisites to learn differential geometry. E.g., as an ugrad, the courses never covered the inverse and implicit function theorems (just local nonlinear versions of what is obvious in the general case of solving linear equations), but I got some good treatments in my independent reading.
E.g., in computing, sure, Bachus-Naur form was easy enough, really is basically just set theory, but I never got how to take such BNF and automatically write a parser. Once it might have been nice to have done that! Or just use Yacc, right?
> Ph.D. requisite?
A good Ph.D. is a good thing. It's the training in how to work with things that are new.
So, learn to zip through a lot of stuff don't need to know well, where K-12 and college and even grad courses have an implicit norm that such zip work is not good. Good? Heck, it's crucial!
Learn the pros/cons of stuff that is new. Do begin to lose patience with things that are old -- too often they are not as good as might assume in a course and should be improved on or even just set aside.
In doing research, just have to look at the material in a more effective way than the usual way as a student trying to make good grades. No longer trying to make good grades and, instead, are trying to do something new, e.g., improve on the stuff in the text books or papers.
Also are no longer hanging on every word of a prof and, instead, are trying to do own stuff.
Some of the coursework for a Ph.D. is also usually darned good. At a good school, i.e., a top research university, the difference in quality is like that between a dinner at McDonald's and one at a Michelin 3 star -- no joke. Or, if have a course in ugrad school and think that the course was fine, if get a course from a good researcher, very bright, who knows the material from various approaches, can get a LOT more. The good researchers are smarter -- and not by just a little bit.
My view is that math, and mostly the advanced stuff and often new stuff, will be the key to the future of computing, at least until the software is able to do math better than humans. Computing only what we can think of without math will become way too limiting.
I'll try to explain it.
1. 20 years ago we were called "computer geeks". Young people fond of computers. This term does not apply anymore. Now everyone under 20 is a computer geek.
My daughter is 5. You know what 5-yo kids draw in school ? User interfaces. That's right. Checkboxes and buttons and sliders. They don't know what they are called, but they know how to use them. Every day they draw UIs and computers and they play with them at school, then they come home and interact with their tablets.
But that is the coming generation. Today, even if you've never seen a computer, you can catch on pretty quickly, because:
2. There is almost no entry barrier into the profession. After a month of tutorials and interview training you can get a job as a junior developer. In fact, there're so many learning opportunities right now that it doesn't seem fair. Anyone anywhere can learn to do what you do - and better, because he can learn from the best. And they can produce better code faster, because:
3. Services like Github have trivialised code sharing and reuse.
Each library solves some kind of problem. Before, it required days or even months of work and research. Now, it's just a 'pod install' or 'npm install' .
But it's good, right ? It's so much easier to develop software now... That's true, however, given the way things are evolving: 3.1. If it has any 'general-purpose' value, what you're working on right now is (or will soon be) obsolete, because someone else will release it as an open source lib. Good for everyone, not as good for all the programmers who would have been paid to develop their version of it.
Of course, we can ride the wave and try to keep current with all that's happening, right ? Well, turns out that's not so trivial anymore, because:
4. The field has become extremely wide and each area is an ocean in itself. Take 'the backend' : there are dozens of languages and frameworks, each of them being updated weekly. Or iOS Development. Machine learning ? Computer vision ? Sound engineering ? .... You did notice this didn't you ?
And if that isn't enough food for thought, then
5. AI will eat our lunch pretty soon. Maybe 5, maybe 10 years from now, there will be no 'programmers', because everyone will be a programmer. The tools, libraries and techniques will be sufficiently advanced for anyone to speak the requirements and design ideas and the AI will write all the underlying code.
AI combined with the 5 year olds of today who are already doing UX design.
Note that this wasn't the case 5-10 years ago. Before the iPhone, Github, Khan academy and Coding Bootcamps, the industry was a different beast. What the future holds is of course unknown, but the signs are that 'programming' is not a skill that will feed you for the rest of your life. Time to think about other things you're good ;).
1) I've been hearing this every 5-10 years for the past 30 years, and it still hasn't happened (which is enough to explain my scepticism but granted doesn't prove anything).
2) The hardest part of what programmers do isn't pasting crap into an editor, snapping blocks into scratch or waving their hands at Jarvis, it's understanding the frickin' problem and thinking clearly about it.
3) The second hardest thing is maintaining that clarity while holding multiple levels of abstraction in your head at the same time. Most people struggle with this and don't really enjoy it. It may explain why people that like maths gravitate to programming (and vice versa).
So, yeah, things are going to get weird (and awesome!), and maybe there will be fewer job codes, but there will be a role for "explains things to computers" until Skynet (or the Culture) is online. IMNSHO.