Disclaimer: I didn't read the full article. I can't stomach these types of "career strategy" articles anymore. This approach to life in general is very misguided (maybe less so if you just want a career to fulfill other goals), but for those who want to pursue a more idealistic life, just pursue your passions. Plan B is being an improv comedian. Plan B is writing the great American novel. Plan B is traveling the world as a war correspondent.
I left corporate world precisely because I felt "planning my career", as I was encouraged to do, was an absolute false way to live (for me). I couldn't reconcile the absurdity of it with the severity of the consequences if I didn't do it. But the consequences are all socially constructed, and they go away as soon as you change your mentality.
When I think of my heroes, I don't think of people who've hedged their bets here or there - they just did what they felt they had to.
Amen. The best decisions of my life were spur of the moment ones. You can't generalize. People are vastly different from one another. Two guys with the same degree from the same school will have varying levels of success in life. Personality and initiative are not taught in school... they can't be.
This reasoning doesn't take into account the fact that a lot of people are very bad at programming and get tired of doing something they're very bad at. We have a fair number of bad programmers in their twenties, few in their thirties, and probably none over 35. It isn't because they get better. The only middle-aged programmers we have are absolutely solid.
"The only middle-aged programmers we have are absolutely solid"
As a several year veteran in the government contractor space and from personal experience as a configuration manager, I strongly disagree this this. I've seen poor and mediocre programmers survive as programmers well toward retirement age. Part of the reason is that programming isn't the only skill that they provide. They provide domain knowledge on the systems which the gov (mil and civilian) rely. Then us poor sods have to clean up after them and clean up after them, and hold their hands on radical new ideas like object oriented programming. I could really rant on this topic if I wanted to.
Another perspective: I mean, how many coders do you know that make it through a few years working who have NOT developed some significant domain knowledge?
That's in government though where the contractor is in many cases above all trying to fill seats to make sure they can bill the maximum amount of hours. They just call it "domain knowledge" to justify to anyone that might question why they are keeping someone who is bad at the job around.
When you talk about government and government contracting you are discussing an entirely different world devoid from reality.
While I cannot fully disagree, I would like to point out that a great many government contractors take their jobs very seriously and do very good work.
Of course, I may be biased since I work as a contractor.
Sure at the individual level there are plenty of people who do good work but I'm referring to the companies themselves. A government contract company's only real goal is to get more contracts in terms of numbers and dollar amount and run them in a way that maximizes profit. A contract companies success in the government realm has little to do with actual performance and a lot to do with salesmanship.
I'm not suggesting contractors beat their children. I am saying that if one wants to move up within a government contracting company they will reach a point when they will have to push a course of action that is not in the best interest of the government at which point the individuals and company are indistinguishable.
You have a certain logic, but all I can say is that I have not witnessed it myself after working now for 2 different contractors. Of course, in both of those cases everyone in my immediate management chain was, like me, a former military officer.
For the lucid moments he has, which people would argue about the frequency of, Alex Papadimoulis discusses something similar to this in one of his site articles, providing what I think is decent insight on why they make it to retirement age:
FWIW, I think there's enough people in this audience that wouldn't be happy holding on to a job they aren't particularly interested in keeping up to date on, simply because they have the domain knowledge to make them "safe". I could be wrong though.
Huh, combine two elements in the article you linked, quoting:
* The higher-up the position, the longer the curve. Changes tend to occur much more slowly at the top. For example, a basic “refactoring” of a department’s teams could take well over a year to implement.
* The greater the skill, the shorter the curve. Ambition and skill go hand-in-hand, and ambitious individuals tend to want swift changes, and quickly lose motivation when these don’t happen.
* The larger the company, the shorter the curve. Large teams are generally not receptive to ideas from the new guy, leaving a large part of contribution (i.e. past experience) wasted. Furthermore, promotions are often based on tenure, not skill.
* The smaller the company, the longer the curve. Smaller companies, on the other hand, are more receptive to change, allowing one to contribute past experiences for a long while.
* The less skill-demanding the company, the significantly longer the curve. Not all companies need top talent. For example, the company who needs only maintainers of an ancient COBOL application might be best fit with curves that are closer to the value convergence."
Notice what happens when you're very skilled in a large company?
I have seen some very poor coders stay in programming for a very long time as well. This is hardly unique to contractors. I think that in the middle of any large organization you will find a large number of people that just drift along either because they have one particular piece of knowledge that makes them hard to replace or else they are simply to much trouble to fire so they are stuffed into a sinecure and left alone.
It's probably worth noting that all programmers above a certain age predated the option to learn programming at home with a PC. That caused the number of new (but not necessarily good) programmers each year to explode.
There is a sweet spot I think between the introduction of cheap personal computers (Apple II, Commodore, TRS-80, etc) and the wide availability of the internet starting in the mid 90s.
In the 80s and early 90s, affordable computers existed but there wasn't so much you could do with one. The list of activities looked something like:
1) Play Choplifter
2) Play Loderunner
3) Learn BASIC
I have to disagree totally. This is exactly the time frame where I learned assembly language (Atari 800) and C (Atari ST, etc.). As a programmer these machine were excellent tools for learning how the guts of the machine really worked, teaching yourself how to program and sharing information with other enthusiasts. Lets face it, how many of today's younger programmers have a clue what a index register is, or even how a cache is used?
You completely missed his point. He's saying because you didn't have eighty bajillion websites, fancy games, and Facebook to waste your time on, kids who were just playing around on a computer were much more likely to start learning something like BASIC (or, as you mentioned, assembly and C). Now those same kids are posting YouTube comments that make me fear for our future. :)
Yeah, sorry. I was thinking about it from the perspective of a 13 year old who has never touched a computer taking his new Vic-20 out of the box and hooking it up to the TV for the first time.
Programming was a natural thing to attempt to do since there was little else you could use a computer for at that time.
That caused the number of new (but not necessarily good) programmers each year to explode.
Your implication is exactly backwards, from what I've observed. People who learned programming as a kid for the joy of it are much more likely to be good programmers. People who went into it for job training are much more likely to suck.
I'm not implying that it caused there to be more bad programmers, just that it caused the number of programmers overall to explode, and that probably adds a lot of noise to any observations about older vs. younger programmers.
I agree with you, but I also started learning to program with a Commodore 64 when I was six, so I'm probably a bit biased. :)
Agreed. Plan B is for mediocre programmers. Great programmers, not good or o.k. programmers, will always be in in demand regardless of age, cost, recessions, etc.
Software and technology more than ever is everywhere and becoming so deeply embedded in our lives that the demands for great programmers shall continue to grow to feed those needs.
It surprises me to read this, when most other times all I seem to read about is how a "shortage of engineers" exists in the world.
I'm 26 years old and I sometimes think of a plan B.
While I've always loved programming, before I even got a PC (14 years ago, loved the idea so much that I started reading a book about programming in Basic before I had access to one) ... I really hate the industry (at least the local one).
Life would be a lot easier for me if programming was a hobby in my spare time. But as it goes, I'm doing a lot of work on projects that I don't like, and when going home I don't have enough energy left to work on things I love.
I don't think I'll ever give up programming though.
If the geezer with 10 years of C++ experience showed a capacity to rapidly learn a new language / framework, I'd hire him every time. Those 10 years of C++ experience taught a lot in terms of general understanding of programming, best practices, how to "think" like a programmer, etc. (or at least one would hope; it varies, of course). That is far more important than a few years using an extremely high-level language.
I think about it this way: I am supremely confident that I could know all I need to know about Ruby/Rails to do just about anything within a few months of working on an honest-to-god project. I'm equally confident I wouldn't know a fraction of C++ in that time. As our tools continue to become higher-level and more acutely focused, they become easier and easier to grok. The learning curve of a language with C++'s history vs. a new-shit-on-the-block web framework? Forget about it. You can write a blog in 10 minutes, remember? ;)
I'm that "geezer". Coded in C and C++ for over a decade, and now I'm working in the magical world of Rails, where I get to watch 20-somethings rediscover the value of old ideas the hard way. (Given the average comment thread on Hacker News, and you'd be excused for wondering why anyone ever used compiled languages or static typing. Silly dinosaurs!)
That said, while I appreciate your sentiment, I know in my heart that the author is right. All of my friends from college have moved out of programming. Many have left the industry completely -- and we're not even that old! The bottom line is that there's little or no cost advantage to hiring an older coder, when I have t-shirts that are older than the most popular development environments.
Every once in a while, some young geek chimes into these conversations with the observation that one needs only "keep up with technology" to stay relevant in the industry. But even ignoring the fact that "keeping up" is usually easier said than done, the economics just don't work out. My friends who went to medical school are finishing their residencies and starting in private practice; my friends who went to law school are making partner. In most industries, you're just beginning your career when you're in your early 30s. In software, you're already old enough to be a conversation topic.
Rightly or wrongly, the impression people get from a a 40+ programmer is that it is odd for him to still be doing this job and subconsciously he comes across as unsuccessful because he hasn't 'moved up the ladder'. I think this is the major impediment career wise for the older crowd.
It is like being overqualified for a job: You have all the skills needed yet your motivation and personality is questioned.
I realize that good companies recognize talent, and that überhackers with brand name projects behind them will always be in demand, but sadly the world is made up of different realities.
That said, while I appreciate your sentiment, I know in my heart that the author is right.
Even the "keep up with technology" people know in their hearts that these articles are correct. Everyone knows programmers have a half-life, they just are in disagreement about when it kicks in. Nearly everyone would be surprised to discover a 60 year old programmer who was still gainfully employed. 50 is really pushing it, 40 is pushing it, and 35 is starting to push it. In contrast, nobody would think it was weird to see a 40, 50 or even 60 year old doctor or lawyer.
It's a bit early for these comments. There aren't that many programmers in their 50s because there wasn't as much need for programmers in their twenties, 30 years ago. Demand for doctors has been more steady.
That's half the story, but it's a big part of it.
The other half is that it's an area with gradual drift out & little drift in.
That half needs some explaining but it seems like more of a young man's game then it is. It's easy to get behind. If you're out for 2 years, it's daunting to get back in. The opposite is true for some domain (like medicine). You get very little drift in to the field (more programmers become HR people or sales people then the other way around). It's a first career, not a second.
It depends. You could be out of Unix or C or Oracle for 2 years and come back. It's only "front-end" technologies like Flash, Rails, PHP, AJAX that suffer from the rapid churn and the latest thing when you come back didn't even exist when you left.
My grandfather was programming for a similar length of time before he retired. He made his last money maintaining mainframe assembler and Cobol programs, though. (He jokingly described himself as a classical philologist for computer languages.)
I remember job ads looking for mainframe programmers of many stripes to maintain vintage systems, as many cobol and assembly and jcl professionals had retired. There is still a lot of it out there.
I can't completely buy it, only because I'm sure there are still companies or projects out there who need somebody with a decade's worth of low-level programming experience. Okay, maybe you can't make tons of money doing Rails CRUD apps because a trained seal could do that, but a trained seal couldn't write complicated C++ code.
My point, I suppose, is that your experience must still count for something within certain domains. Right? Or am I wrong on that, too?
Damn straight! The outfit I work for builds medical instrumentation and you can bet your butt that experience counts a huge amount. It's also getting harder to find people with recent C++ development on their resume.
I think you'll find that in industries where safety & reliability is critical, experience is always a great benefit for the applicant.
My friends who went to medical school are finishing their residencies and starting in private practice; my friends who went to law school are making partner. In most industries, you're just beginning your career when you're in your early 30s
I wonder how much this is to do with the relative newness of programming as a profession. Medicine and law have had a very long time to develop systems to train the young, then identify and reward the knowledgable and talented. Perhaps in a few decades 20-something and 30-something programmers will be regarded in much the same way as their law and medicine practising counterparts.
"How long will people continue believing in the myth of the 15-year-old hacker genius while simultaneously decrying the unreliability of software before the cognitive dissonance finally cracks?" -Dave Herman (http://calculist.blogspot.com/2005/12/12-weeks-with-geeks.ht...)
Also, programmers who have been working for >30 years (who started before the mid-late 70s) didn't have the option of learning to program at home, on a PC. PCs caused the number of new, but not potentially good, programmers entering the job market to spike.
Bingo. I remember being an undergrad watching all the other majors play frisbee while we suffered. "That's ok", I remember thinking "this has to pay off. I mean, why else would we be doing this and not enjoying life? Wait until we graduate, then we'll see whos living it up!"
A dot com crash and several cube jobs later, those same folk are living in better homes and driving luxury suvs while I am pondering how I can escape the hell that is a modern day software cubicle job....Guess the joke really is on us.
Exactly. I was hired on as a Principal Engineer at a Rails shop despite having literally about 3 hours of experience using Rails. But, I'd worked with the rest of the senior technical staff before and they knew that just didn't matter. Sure enough, a couple months later I was submitting patches to the framework.
The other thing about new technologies in general, and Rails in particular, is that 2 or 3 years of experience doesn't really mean much because the evolution is so fast. There's lots of Rails lore out there on the web which is completely out of date, and if you're not willing and able to dive into the code yourself and design your own experiments you're going to make completely incorrect decisions about how to design your app and write your code.
Everything you say is true, but you are leaving out 2 major factors that are brought up in the article:
1. The "geezer" with 10 years of C++ probably wants a lot more money than the guy straight out of college. If the company both needs that expertise and can afford the premium then they will definitely go with him, but if money is an issue they may be happy to take the younger guy for lower pay.
2. The guy with 10 years of C++ may be more qualified than the hiring manager. If the manager is focused on the needs of the company of course this is no issue, but if that manager is some middle management person in a large organization who is worried more about his little fiefdom then the company as a whole, he is likely to avoid any candidate that might overshadow him.
You'd hire her, I'm sure, but would you pay her 70% more than the kid out of college? Because in reality you probably won't get 70% more value out of the experienced candidate.
Because in reality you probably won't get 70% more value out of the experienced candidate.
I was a fresh graduate once. I remember my productivity less as "60% of that of a twenty-year veteran" and more as "It is a miracle that they allowed me into the room for a purpose other than to empty wastebaskets, to say nothing of permitting my code in shipping products".
For that matter, I don't think I had 60% of my current productivity as recently as 2-3 years ago. I can still see my first commit at the day job in the repository. That code is an offense against God. It took me two months to get working the first time and then another two years of squashing periodic bug reports. (Unit tests? What is a unit test? Is that something you do with Subperversion?)
My product's code, particularly the parts of it which were laid down earliest, is so bad in some points that I wouldn't pollute a repository with it if I were rewriting today. Oh, God, the print logic. I can quote one line out of that file by memory:
I know a developer who was learning two new programming languages and started writing serious production code within three weeks of starting his first job post graduation. He took over maintenance of a complex application and rewrote it in a new language. He managed to double his salary 18 months into the job. There risk in hiring someone unproven, but you can buy that down quickly.
The point isn't that they produced something shiny, but the quality of the code that backs it up. The link you presented did not link to any source code, but to a marketing blog. The quality might be horrible, but they shipped it.
If you are not 3x as productive 15 years after graduation as you where when you just graduated you are probably doing it wrong. The only advantage to employing young people is their willingness to work insane hours, but that pales in comparison to experience.
Sorry. I'm coming up on 15 years, and I am not 3x more productive than the better young developers I've hired. I just don't think this sentiment is valid.
better young developers I've hired that's not what I said. Are You ~3x as productive Now than when You started? It's not a question of typing speed or syntax, it's a question of what you can get done in a 1 month. And how much damage you will do in that same month.
One of the better examples of this is helping to debug someones program. Now I frequently hear, I was trying to do X, it almost works, but it's also doing Y, and I will say ok you made a mistake in this area. It's not just understanding code, but also understanding the typical mistakes we make. Tracing down an off by 1 error is something everyone learns, but they don't teach it in school.
Young developers can be, and often are, highly productive but software development is more nuanced than just raw lines of code. Sensible design is both very difficult and very important and I don't think anybody gets very good at it with less than 10 years of experience.
The first 100K lines or so are easy and somebody with talent who is fresh out of school is going to get to the finish line at least as fast as a 10 year veteran. The real test is the next 100K lines of code which the experienced designer is going to breeze through while the novice is about to learn an important lesson: Writing large programs is much harder than writing small ones.
You're missing the point, I think. Higher-level languages just reduce the number of lines before you start to hit the maintainability wall from poor design. So, while maybe it's >100K lines of C that's where it typically happens, it might only be 10K or 20K lines of Ruby.
A few year's real commercial experience is often enough to at least double someone's productivity, often much more. Why? Familiarity with all the things that aren't pure coding. Understanding requirements/domain knowledge. This is the big one, if you are working in field X and you know the terminology, the business and so on, you can find out what people need and solve their problems with no messing around. Just to pick an example I am familiar with, banking, in pretty much every programming/IT job ad it will say "must have previous banking experience".
Plus there's experience with the toolchain. Experience with the codebase. Knowing how to play "the game" of meetings and reports.
OP glosses over one critical truth: programming is not just about delivering code, it is about delivering value.
In spite of what many of us technologists may think, customers and employers do not purchase "software", they purchase the benefits that software delivers. These benefits come in many forms, and it's just as likely that they come from solving general problems as well as solving technical ones.
If someone at any age complains about their difficulties securing work, it's not necessarily because of their technical skill set, it's because they're not delivering the value their customer covets. They need to find out what their customer needs and deliver it, whether that means brushing up on their skill set or not.
When the posers and BS'ers meet their makers, it's not necessarily a bad thing; I prefer to call it "industry Darwinism".
For the sake of imagining someone working at an employer where they have no real control over the direction of the product, what value do they bring other than their technical skill set and analytical ability? Presumably the value most developers out there deliver is producing a coded up version of someone else's specification. Outside of having enough business acumen to know when to shut up before the management threatens your employment (if remaining employed is important enough to you), what else is there?
"...they have no real control over the direction of the product..."
Not my experience. I (and almost every other programmer I have ever met) have had some control over everything I've ever worked on. Perhaps this is a self fulfilling prophecy: if you don't think you have any control, then you don't.
"Presumably the value most developers out there deliver is producing a coded up version of someone else's specification."
Not my experience either. At least on this planet.
If anyone else ever produced a specification rigorous enough for me to code from, I could die happy.
"if you don't think you have any control, then you don't."
Or you've tried to get some control, and have had your hand slapped away. And then realize the part that you don't have control over is the crux of the product's value proposition, and that it is a bad value proposition. Having control of the how isn't going to make it valuable enough, because it doesn't solve the right root problem. If you've ever tried to push a certain direction, only to have people respond "that is management's decision, not yours," that's what I am referring to. Perhaps you have never experienced that.
"If anyone else ever produced a specification rigorous enough for me to code from, I could die happy."
That's not quite what I meant. My point is that, in a large number of development shops, this is the way people deliver value. Their manager and the organization he represents is the customer, and often times they already know what they want, even if it is the wrong solution. It comes in the form of a specification, even if that is badly written. The value they bring is their technical skill set, such as it is, because most of the other decisions regarding the product have already been made by the time it gets to them.
I'm not ascribing this method of delivering value to you and those you know, nor to I and most of the programmers I know. I'm ascribing this to the people in the stories they and I tell of the other programmers we've met who operate this way: offering technical skills, and otherwise having faith everyone else will figure out the customer value part. Some are getting Darwined, as people find out they don't even provide what they claim to offer, but enough people out there find good value in a cog.
By the time you turn 40, you may likely have a mortgage and family. Packing the family up and selling the house to pursue a more challenging development job in another area is just not feasible, especially when your spouse has her own career. The "Plan B" suggestions given by the author are good for people in this situation. A few more are teaching software development and writing about technology as a journalist.
Most software in the field today (80% is the figure I read - trying to find the article again) takes user input from a screen, queries a database, and sends results back to the user. After developing enough systems like this, you realize only the technologies are changing, not the problems solved. Keeping up with the latest tools does not change the dull repetition of this reality so you can easily lose incentive to keep up. And, frankly, I'm not sure companies need to pay someone with 20 years experience to do such mundane development.
Interviews for my last couple of employers centered more around growth in the organization, ie. understanding business processes, the business' industry, and organizational dynamics, not on technical knowledge. I think there comes a point when organizations begin evaluating a potential employee on potential to grow in the organization rather than grasp of functional vs. imperative paradigms, etc.
If staying a developer is what you really want, then it's probably worth learning another problem domain. Perhaps mining biological data for patterns, etc. (Heck, despite advances in neuroscience we can't explain why a stroke causes memories to "move" to another set of cells in one patient but are lost in another patient. There are plenty of problems to be solved.) Anything that makes the field fresh again. (Of course, you may run into the same problem I stated in paragraph 1.)
Packing the family up and selling the house to pursue a more challenging development job in another area is just not feasible, especially when your spouse has her own career.
A good reason to live in a tech hub, if you want to be able to change development jobs without changing residences.
I would like to point out that these don't simply fall out of the sky. They are something you sign up for voluntarily (at least in the civilized world.)
voluntary. you don't need to get permission/contracts set up with the government/people to love (see "free love" on Wikipedia), and you don't need to take loans from banks (see renting vs buying articles, especially 'is renting throwing money away?' or something like that from earlier in the week on hacker news). // free love advocacy: complete.
It's great money, but not good enough to swear an oath of celibacy for. Especially if you can just keep the same amount of money, find a spouse who makes a few dozen kilodollars of their own, and then not be so lonely.
This logic is so broken. Languages and dev platforms may change every 10 years. C++ may get stale. But image processing, or compression, or security, or low-latency high-throughput congestion-aware network protocols, or what-have-you don't.
Just don't pick things to specialize in that are guaranteed to date themselves. People who did program transformation masters theses in the mid-90's are just now coming into their own in the industry.
I asked this elsewhere, but I'll ask it again here, and I am being completely sincere. Why pick things to specialize in at the expense of other things you elect not to?
Specialization is not free; it decreases flexibility, and would seem that it would decrease cross-pollination of ideas from different areas of knowledge. It increases income, for sure, but also increases the attendant risk that people won't have need for an X specialist right at that moment, or at least no one you would want to work for.
I'll grant that generalization is not free either. Someone who really needs an X specialist will pay top dollar, because the supply is likely pretty low. And people may not trust a generalist to go and implement some specialized X performing application.
I think there are opportunities and attendant risks for both. I really don't think either one wins outright. But, I'll be happy to listen to words of wisdom you might have on this.
Really, your post answers your question. There is value (and risk) in either specializing or generalizing, and there is room in the world (and the job market) for both.
Personally, I am a database specialist. I do have skills in other areas (I do python coding as a hobby and I can write C# code that at least works), but my strong suit is definitely in databases, and even with databases I focus on MS SQL Server and Access with just a little experience in some others.
I personally chose to do that because databases appealed to me and by specializing I could gain a depth of knowledge that very few generalists can. In terms of careers this limits my options somewhat, but it means that within my particular domain I can out compete most others. When the company needs a generalist that can do a lot of things, I am probably not their best choice, but when they need someone with a deep understanding of SQL Server and relational theory then I am a good candidate.
None of what I wrote above exempts you from keeping up with the superficial trends of the industry. If things shift from J2EE to Python on the DLR with .NET libraries, you still need to keep up with that stuff. So yeah, if you're stuck with recruiters (and, don't be), be keyword compliant.
But the big scary force in this article is, "over 10 years, your C++ experience makes you progressively more expensive and less attractive to a Ruby shop". That's true, if all your 10 years were about was C++. C++ is a distinctly dumb thing to build a career around.
"C++ is a distinctly dumb thing to build a career around."
For that matter, so is Ruby, Rails, Python, and everything else that's popular today.
In ten years, everyone will be using Blub, and badmouthing those dumb ol' guys who were slogging around in Ruby. It's the one thing in life I can guarantee.
I agree completely, in case it sounded like I was just ragging on C++. When I do that, I accompany it with all the many reasons why C++ deserves the treatment. =)
So yeah, if you're stuck with recruiters (and, don't be), be keyword compliant.
Most recruiters and big company HR departments are among the biggest destroyers of meaningful language there are. "Keyword compliance" is just another of the forces trying to dumb us down and turn us into automaton neurons in a big brain, exchanging and processing signals we don't have any inkling of.
I got my first programming job in 2002, because I knew Pascal, If you where a consulting firm with 10k employees then you need to keep up with industry trends, but we are not. You can try and keep up with all the latest trends, but it pays better to focus on about 3 areas and know a lot about them.
Sounds to me like you and the recruiter have totally different target audiences.
Just my two cents, but I think you might be doing yourself a disservice by dumbing your resume down to their level... Unless the type of job you're looking for is just a cookie-cutter "latest pet framework" position.
But in a work environment it's often not your choice to pick what you work on. I tended to find that those with the experience were set on legacy systems, and the new technology went to contractors, or were outsourced. And no matter what your 'application experience', any chance at employment elsewhere became based on your 'language/platform experience'.
Sigh. Over 40 geezer checking in, but because I spent my 20s pursuing a music career, and then a number of years in QA, I've really only been doing pure software development for about 4 years. The problems I've been encountering these days mostly center on the physical demands of the job (typing and sitting) -- joint pain, back pain, tendinitis, etc...
Yoga has been helpful, but I'm wondering how long I'll be able to cope.
On the physical demands (speaking as an 37yo coder), I've found these things to be very helpful...
- yoga (which you've got covered)
- a kneeling chair does wonders for posture
- placing your monitor at the proper height (eye-level is 1/2-1/3 from the top of the screen otherwise you tend to crane your head forward and downward)
- stepping away from the screens regularly (set a timer to remind you because it's easy to blow this one off)
- eye exercises (especially this one...alternate focusing on the tip of your nose and focusing on a far distance)
Not sure how you could use wrist rests, or why you'd want to. For a horizontal keyboard, wrist rests prevent you from bending your wrist harmfully. Of course, they also let you get lazy.
For the vertical layout, the spacing of the keyboard prevents wrist bending: the two sides of the keyboard are roughly shoulder width apart. When you aren't typing, the natural thing to do is put your hands in your lap.
I think there are some other questions that need to be asked here. I'm not sure exactly how to phrase this:
"Of the software-centric industries, what percentage of employees are actually writing software? What percentage of software developers do not work in these industries."
I don't know the answer to that, but for some reason I think it's well under 50%. It tends to (on HN anyway) get presented as the coders & management. But (IMO) that's too simplified to mean much.
Programming makes sense as a starting point. It's a relatively straightforward, transferable & acquirable skill set. On the other hand, things like account management, or sales may require the kind of skills you need experience to gain & are hard to develop intentionally.
Also, I think it's relatively easy to shift from coding to something else organically, but not the other way around. If you are a programmer that ends up making software for the agricultural industry , you may pick up all sorts of skills & knowledge that make you useful in other areas. If you enter that industry from another end (even if you are very close to the software), you are unlikely to become useful as a programmer. At least not without intending to.
You wouldn't be surprised to hear this story: CS degree at 22, worked as a developer of farm management software for 5 years >> a (software/technology) consultant in agribusiness for 5 years >> a manager/executive/account manager/marketing person etc. for irrigation supplies manufacturer >> something else.
You would be somewhat surprised to hear the reverse, someone with 10 years industry experience leveraging that to create software for that industry. It's not impossible, but it's worth remarking on. It probably means that either the person was a programming amateur that went pro or that they actively decided to retool themselves via a path of quite a lot of existence.
What ever happened to the view that some programmers have a capable productivity that is entire orders of magnitude over others?
I think most employers just look at keeping expenses to a minimum. This means ruling out the concept of pair programming, because why would you consolidate two into one (even temporarily) when you have a brick and mortar mentality to construction that points to keeping everyone busy? And most importantly, young employees need to pay their dues. That means lower salaries for a while, and toleration of extra abuse.
I wonder how accurate those statistics are. For example a dozen years ago I was called a programmer, now I am called a project manager, but I still work in software in the same group for the same employer - about as good longevity as you can get. It may be that seniority leads to job relabeling that misrepresents the true situation.
The real question is whether the people who "drop out" of the statistics still wanted to be "programmers" at 40.
What percentage of mechanical engineers still work as "engineers" a decade after graduation? The stats for CS majors are meaningless without a baseline for comparison.
Hiring by resume keyword is good only for recruiters, internal and external.
Most jobs [citation required] are found through networking. My advice is to make that your plan B, if you feel you need one. Network all the time.
As noted elsewhere in these comments, the ability to pick up a new language is not really the critical factor in experience.
The value of experience includes 1) knowing what not to build, that is, avoiding building the wrong thing 2) knowing which approaches don't work, or avoiding building the thing wrong 3) being able to pick up the technical parts of a project thoroughly--the language, code, design in good time.
This is helped by a mindset of taking the initiative for your own education, and never stop learning.
Does anyone still think it really matters which programming language a developer has experience in?
It didn't take long at all after working full time as a developer to realize that software development is much more comprehensive than simply knowing a language. Shouldn't we all be able to create software in any language after a short ramp up period to learn the new language?
Some languages are really different, function, object oriented. While you can learn to write code in a new language fairly quickly, figuring out what the best practices are in a new language, what libraries are reliable, can take much longer. Maybe learning a new language the runs on the CLR/DLR or JVW isn't quite as different, but languages are ecosystems that take experience in order to make good decision.
The industry turns on a dime, but is slow to retire proven technology.
I have been slow to retire vim. In fact, I keep learning new things that make my work easier (like :arge filename --- the e means it's like :e, to edit a file, but it also adds it to the arglist, so you can move back and forth the list of files with :n and :p; and :tabnew, ^PgDn and ^PgUp give you tabs and switching between them).
It seems inevitable that the day will come when the Eclipses and IDEAs of this world are more productive (some say it already has), and when it does, I won't be up to speed to make the switch. I don't think typing support is critical for understanding problems and solving them, but it helps.
Has anyone considered the possibility that maybe the workhorse technologies in software development have begun to stabilize? C, C++, SQL, Unix etc. has been around for some time. Java and .Net aren't going to go away anytime soon. We may yet see some disruptive changes in Web development, but I doubt whether the basic Javascript/HTML/CSS scheme, or PHP/Python/Ruby set will become obsolete anytime soon.
My plan is to ensure that I can always deliver valuable software and maybe even create some that I can own. A lot of my friends are doing their MBAs - I just don't think that route is for me.
The similarity raises a question for me--what are the defining characteristics of a vocation without longevity? What do I do if I like this computer stuff, and hate doing management stuff, but just turned 30 and can't claim anything near "guru" status?
I can definitely see how this force works against generalist programmers. I can definitely see how the market limits the shelf life of a generalist programmer.
So specialize in something where those years of experience accrue to your benefit. 10 years of image processing experience will make you an industry thought leader, as would 10 years of cryptography or 10 years of compiler backend design. We aren't running out of applications in these fields.
I can definitely see how this force works against generalist programmers.
Come on now, what basis do you have to say that someone who is a generalist is unable to provide value to people through the software they write? Do people need to be excessively specialized to make something people will pay money for?
And for that matter, I could see the generalist programmer fairing better, because they don't lose the general theory things are based on while diving incredibly deeply into a narrow body of very specific knowledge. If the job/labor/consumer/whatever market presents some new area of need, they're in a better position to go learn and capitalize on it.
There is one more fundamental reason. When you getting aged you have less time to stay tuned with all changes in your field.
Of course, if you have a contract to maintain some old system, or playng a key role in some long project with solid finance - that is ok. But on the field motivated younger guy will easily outperform you, because you have many things to do as an adult. You simply cannot spend days and nights with laptop.
So, there are two obvious directions how to reuse your experience - project management and work as a system architect. But these positions are rarely vacant, so, you probably should start your own project or a joint venture.
There is no use to try to compete with younger generations on their field (coding). It is much better to reuse your own experience and use thier energy, naivety and enthusiasm.
I left corporate world precisely because I felt "planning my career", as I was encouraged to do, was an absolute false way to live (for me). I couldn't reconcile the absurdity of it with the severity of the consequences if I didn't do it. But the consequences are all socially constructed, and they go away as soon as you change your mentality.
When I think of my heroes, I don't think of people who've hedged their bets here or there - they just did what they felt they had to.