I am 55 and have been programming computers since 1975 when I was 15 years old. Do the math, I have been programming now for 40 years. Recently, I had a conversation with someone else about this topic and I told them that I have never been so excited about my career, the field of computer science, and most importantly the opportunities that exist today in the field of technology. The excitement surrounding too many topics to list is amazing. I only hope and wish that I am able to stay healthy and continue programming to the day I die.
Me 3! 56, first prog job was in '87. Now I'm steadily employed in a dream job, working from home, writing mobile apps and exploring new "IoT" technologies. If this job ends, which all jobs do sooner or later, I'm hoping to starting my own company, finally, and ride that into retirement. But life continues to be an adventure and you never know what lies around the next bend in the road!!! Best of luck to you and to people of all ages in this amazing field.
Just turned 50 yesterday. Wrote my first contract program in 1982 when I was 17.
Today I teach teams how to rock-and-roll. I also keep coding, but mostly as a hobby. It has nothing to do with programming -- I simply have too many irons in the fire to do all of the things I love as much as I want to.
I guess I might as well pile on. Turned 50 last year. Got my first paycheck for writing code junior year of high school (writing BASIC code on a Commodore PET!) Working on my fifth startup now.
I can't imagine all the technologies and skills you guys have acquired.
If I may derail the conversation a little bit, may I ask if/how you use the things you've learned today?
I mean, is it things like paradigms that have stuck with you like OOP/functional/w\e, or do you always structure your exception handling in a certain way, no matter the language? Are there skills/technologies you've been using since you've started? For example little scripts of basic that you've never let go off that automate things like setting up build servers and the like?
SCHiM: "is it things like paradigms that have stuck with you..."
For me it's always been about problem solving rather than simple fascination with some particular technology. If I can solve a problem with a keyboard macro in Emacs, great. If it requires Perl or Java or javascript, so be it.
I try to use the tool that's appropriate. If I can solve a problem quickly and move onto something more interesting, one-and-done.
If I have to stop and learn something new (e.g., WKWebView in iOS ObjC) to get my task done, so be it, and I'll put in some late nights to get there because at my age, I'm a bit paranoid about looking bad so I try to give the good folks at HQ no reason to doubt me. I spend a lot of time on Stack Overflow and Youtube doing concentrated learning.
But the real thing is what others have also mentioned: properly defining a problem that needs to be solved, proper communication, keep good records, and try to maintain transparency, honesty, and pleasant comportment at all times.
Honestly the older I get, the less I notice people's age. If someone half my age knows something I don't, then the way I see it, they have something to teach me. I've been to many conferences and watched many youtube tutorials where the teacher was very young (from my wizened perspective) but the information is why I'm there and that's all I care about.
What do I think about young people? (you didn't ask but I'm saying it anyway)
I love young people. They have so much spirit, so much energy and creativity. I keep hearing critical (snarky) things about millennials this, X-gen that. But I don't see it. The young people I've been around (for a while I was back in school full time, surrounded by 20-somethings and a few 30-somethings) were a joy. Fun, humorous, inquisitive.
Everyone has his faults, not least myself, and I believe as we get older we become more tolerant of others' faults and shortcomings. In fact that may be the single hallmark of growing older (apart from physical issues).
No more BASIC, but I still code in Common Lisp whenever I can. And I'm using some library code that I wrote when I was in grad school 25 years ago.
Once you grok Lisp, everything else is easy. You come to realize that the vast majority of what passes for "new technologies" is really just a re-discovery of something that exists (or is easily implemented) in CL. That makes it a lot easier (if a tad frustrating at times) to keep up.
EDIT: CLOS, and generic functions in particular, are a HUGE lever that no other language has co-opted yet.
You come to realize that the vast majority of what passes for "new technologies" is really just a re-discovery of something that exists (or is easily implemented) in CL
So much this. (From a soon-to-be geezer who's staring down 40 soon.)
Julia has generic function but they are not defined in Julia itself nor is dispatch mechanism can be extended in Julia itself. CLOS is all about meta-circular semantics so I wouldn't include Julia in there (at least not fully)
GOOPS[0] in guile is definitely hugely inspired by CLOS, which also has generic functions with multi-method dispatch.
I highly recommend guile to anyone who wants the battery included nature of common lisp. I know that racket is also a great choice here, I just have little experience with it.
Racket's object system is largely inspired by Java. So is its statically-compiled module system (in which you can't change anything once it's been compiled, unlike a real Lisp), and Raco build tool. Programming with objects in Racket feels a lot like programming with Java objects in Clojure.
I'm not quite in the same age range, but north of 40, and have been doing this for > 20 years.
The tech changes - I don't use BASIC or Z80 machine code day to day. The skills that I can speak to, and the skills I see from others with this level of experience, are problem solving and communication, and secondarily the confidence that comes from having made mistakes. Few projects fail miserably solely due to technical issues and skill; in my experience failures come about because of poor communication (including documentation, but also speaking, reading body language, office politics, etc).
We younger folks are incredibly curious about what you've learned. Can you elaborate on the topics you mentioned or recommend other sources? Can you give tips on best practices?
Not sure I have any specific sources to share (others might) but after working with all types of hardware, languages, business realms and what not... you start to see patterns. Human behavior patterns, mostly; the same sorts of needs were there 30 years ago as are here today. People need stuff done yesterday, don't know how to describe what they want, oversold a client on something, etc. The numbers may be bigger, the gigahertz faster, and the memory far greater than people could have imagined, but the problems of translating what people say in to what they want via code is ... fundamentally still the same.
A 16k RAM module was ... $200 in my early days. Then a few years later I got 512k for only $150. Today I can get a 16 gig USB stick for $10, at at a local grocery store checkout aisle no less.
No doubt technology has changed and become more ubiquitous. Peoples' expectations of what's possible and what's normal are somewhat different today than 10-20-30 years ago, but the communication problems are still largely the same. Who's in charge of a project? What are the parameters? What defines "success"?
I'm not sure there's any real silver bullet here - most of the "mythical man month" stuff (from even before my time!) is still largely true (speaking in generalities because I can't think of every single line right now).
Learn to figure out how to communicate better - emails, phone, IM, paper, phone, f2f, etc - they all require different skills, and have different impacts on different teams.
Happy to answer more specific questions here or via email - mgkimsal@gmail.com - not sure if I'm just rambling now or not.
Back in the early 90s, I was doing mac68k programming. Very large Inside Mac volumes were pretty much the only documentation for anything - no stack overflow, no internet, no searchable docs. Almost everything was closed source, and many people wrote their own data structures. When programming Macs, if there was any kind of null value dereference or pointer problem the computer usually crashed and you had to reboot.
The main thing I learned was to be able to look at code and determine if it was going to actually do what I wanted it to do without having to run it through the debugger a couple times.
It's important to spend time thinking about and reviewing code when edit, compile, and test cycles start to get long. There are a lot of instances where that still applies, such as with multi-threaded programming, integration testing or long running jobs.
I also learned the value of having muscle memory for APIs. Sure you can look things up in a jiffy, but actually rote memorizing stuff that is used often can speed development up.
Interesting the pattern in this thread - I'm 57 and started in 1973!
There's plenty of languages I've used over the years that I have no use for today, or hardly even remember: Basic, FORTRAN, assembler, Pascal. None of those languages even had exception handling, so it's hard to say that it influenced my thinking on the subject, except by forcing me to be familiar with the alternatives.
Today it's C++ and C# that pay the bills, with as much Python as I can sneak in. Next up in the queue is Javascript, for which I'm admittedly overdue, but that one's entirely on my own time.
Just curious, as you moved from language to language do you think there were any patterns as far as the timing of your moves? Did you jump into new languages as they emerged or wait for them to reach a stable mindshare within your peers? Or perhaps waited until you needed to pick up a new language in order to pay the bills?
Basic was what I started with, as did a lot of people from that era and after, just because it was simple and available. FORTRAN I tried on a lark, then got serious with it when I moved to the University mainframe. That's where I picked up the first of many assembly languages, after finding out it was the only way to take full advantage of the OS and achieve the best efficiencies. It's also where I learned Pascal, which was an up-and-coming teaching language, and it soon became my go-to language for many tasks. Between Pascal and assembly I was good through about 1990, when my job required me to use a Unix server, and of course the natural language there was C. That led to C++, first on my own time then at my next job in 1997. There was a short period where I found myself applying OO concepts to assembly code! C# was a recent addition for a job-related task where it was an obviously better choice than C++.
Python is the interesting one of the bunch. I was exposed to it about 1995, when a coworker selected it as an embedded scripting language for our product. I didn't pay much attention to it at the time, as it was outside of my immediate responsibilities. It was selected again as an embedded scripting language at my next employer around 2003. This time I paid attention, and came to love it. It's the language that lets me turn my thoughts into results the fastest.
Thanks for asking the question, I've never stopped to think about my programming history in this much detail.
Thank you for a thoughtful, detailed response. It seems like a mix of job exposure and natural curiosity led you from language to language.
Throughout this thread, I've noted a distinct lack of dogma about everyone's evolution as a programmer. While I imagine there was some of it during the popular phase of many of these languages, it's nice to see mostly pragmatism in everyone's career journey.
Here is the first program I ever entered into a computer.
1 8
+ A 5
+ 0 0
+ 6 5
+ 0 1
+ 8 5
+ F A
+ A 9
+ 0 0
+ 8 5
+ F B
+ 4 C
+ 4 F
+ 1 C
I remember how much like some kind of incantation it was. I still get that feeling. And I've had the good fortune to work some fun, powerful, and interesting magic with those incantations.
I suspect that most younger people haven't yet seen their tech choices slip into decay and disuse. And they hang on tightly, hoping to expend less effort in learning as time goes by and they master that tech. It's a vain hope. The essential part of the experience is the underlying creativity, the joy of getting to the next ledge, and really understanding what a marvelous thing a computer is.
I fell as you guys. I am very excited with technology since I started. There is so much new and interesting things to play and read that I have no time to do it all.
I can clearly that each year more and more interesting things appear. The speed is also increasing, in way I can't digest it all. It's difficult what to choose, to prioritize is the key to deal with it.
I always get myself wondering how much new things I will see next years.
I'll be 52 this November. Have been coding mostly as a hobby since '83, with peaks in programming intensity at different stages of my life: sometimes to scratch an itch and sometimes doing some contract/consulting work. Still try to hit the computer whenever I can, but my health's been letting me down lately - nothing too bad, but it's been affecting the focused time I need to do programming right.
So now when I sometimes think of my mortality, the thing I regret is the programming I can't do when I'm gone. Or maybe there is programming after death? I'm hopeful. :)
In the meanwhile, the free time that's opened up from not programming as much is being wisely invested. I'm working hard on my guitar, and before I go dammit, I'm going to shred like a pro!
Almost 51 and I'm only a couple years away from my 40th programming anniversary. I can't imagine doing anything else ... I get paid but it's not work for me!
What are you doing that it's keeping your interest?
I sometimes find myself getting tired of technology and while I love software development, I often think about not doing it anymore. After a while it gets old constantly dealing with other people's decisions.
An easy example is working with Powershell Remoting can be a nightmare if you're not intimately familiar with both Windows itself and Windows Remoting specifically. It's extremely hard to simply use it as a shell without so much deep knowledge, something I don't find to be the case on unix systems.
Absolutely not an attack on Windows, just a recent example I've come across where I don't want to have such a deep knowledge of Windows, but I'm forced to in order to deal with a tech that, in theory, should help me be productive without having such deep knowledge.
I have my days where I just get tired of it all. The day I realized IIS forces you to load DLL's in child applications because the parent loads a DLL (even though they can use separate app pools) is one example. I can't imagine why that's the default.
I find myself having to go home and work on things like homegrown emulators and the like just to keep up my love of technology.
>>I sometimes find myself getting tired of technology and while I love software development, I often think about not doing it anymore. After a while it gets old constantly dealing with other people's decisions.
I feel like you have the beginnings of an entrepreneur here. You should start something that solves this problem you're seeing. The last 2 people I've heard make similar comments ended up starting their own tech-consulting firm. :)
1. "Hate it when X becomes Y and you actually just wanted Z"?
2. "Make an app or start a company that can assure people that X will become Z as quickly and painlessly as possible"
Sounds like you mostly have issues with Windows? If you were using open source software, you could use your considerable expertise to help improve the issues you've found.
> I sometimes find myself getting tired of technology and while I love software development, I often think about not doing it anymore. After a while it gets old constantly dealing with other people's decisions.
I feel you here. I've been the go to sysadmin at every startup I've worked it. Whether it's Windows Servers, vSphere clusters, VLANs on HP or Cisco, it gets old doing the same thing at a different datacenter every couple of months. Especially when you have to learn some vendor specific crap that will almost NEVER be relevant to anything else outside that specific use case.
Thankfully I've been able to move (push? ;) my clients onto more open technologies like Linux, LXC, Openstack etc. all of which means the skills I learn doing this sysadmin stuff are at least tangentially relevant to my main job (unified comms development).
Ultimately like a lot of oldies here (myself included ;) working on the stuff you really want to do in your spare time is where you learn the cool stuff that helps you land the next great gig.
My dad just retired from a programming job at 66 years old, and now he's back down to one job, doing programming at his own business for clients like big manufacturing companies. One of his complaints before his retirement is that some of the younger people, including some in their 50s, weren't willing to try new things or follow state of the art practices.
Just have to say how encouraging this thread has been. I'm 37 and have been thinking about what my career looks like when I'm "old" :-) Thanks for giving us relative rookies some hope.
I'm approaching 50 and I think programming is more exciting now than it has ever been. There are so many interesting technologies out there that I want to learn, master, and use (e.g. Elixir, Erlang, Clojure, Swift, Lua, Haskell, and myriad frameworks).
I also like the way open source options have completely eliminated the necessity for me to work with commercial languages and technologies, which I always found a bit tedious.
It truly is an exciting time to be a software engineer. Barring any serious illness or accident, I'm looking forward to doing it for another 30 to 40 years.
Tangent: I find it interesting that Erlang is an emerging technology that you are interested in learning at age 50, and yet it has been used in production with a steadily growing community since you were in your 20s. It has simply taken a few decades to grow enough to be a common item on programmers' radars.
I find it fascinating that the gradual adoption of new technology maps onto human time spans like this. This makes me optimistic that even technology that is far ahead of its time can succeed when developed with patience.
It helps that you can run it for free on anything from an iDevice to a hand crafted hipsterbuntu server farm, where in the past you had to do it on expensive Ericsson kit deep inside of telco land.
Also 55, though didn't start programming until 1978. I love it, but I'm more apprehensive these days about being able to continue as the free-lancer I've been for the last ~15 years. I have a few biz ideas (and still riding one from 18 years ago that has made me a tad lazy), but sorely need a collaborator or two.
Maybe I should do a graybeards Meetup group or something. Get some reverse-discrimination going...
I'm only 35, but it's obvious there's a lot of work to do to "master" a particular language, or at least paradigm. At the point where you feel you've mastered something, or you've reached the point of diminishing returns? Move to a slightly different paradigm, re-apply your accrued knowledge, learn new things, and grow more.
Yes, the field can be insular, yes, there's benefit from cross-pollination from other disciplines, but the field is vast, and it's reach is still expanding. There are plenty of people immigrating and emigrating from CS that are sharing ideas, you don't have to be one if you don't want to be. If you're happy with what you do, and you can make a living doing it, enjoy it. It's privilege, not a curse.
> I have never been so excited about my career, the field of computer science, and most importantly the opportunities that exist today in the field of technology.
I am in the opposite side, I am also very excited about computer science so I focus now on sales and business development because I can earn much more than developing software. Now coding is a hobby again and a complementary knowledge to sales.
I am 57, been programming professionally since '79, still doing it on a part-time basis, which is perfect for me. Taught me some Angular awhile back. RethinkDB looks interesting. I agree with all who have said that now is the best it's ever been for a dev; web, OSS, cloud, so much power and leverage. I can't see myself not doing some software development well into the future.
Exactly. Remember that disease called 'progeria', where a young person ages physically to be old in like 20 years? Yet they still feel like a 20-year-old? That's me, except it took 50 years to get here.
I.e. There are plenty of 20-somethings that learn one tool and don't want to switch. Don't blame age on a 50-year-old being stuck using the tools they know; blame the person.
I’m 43 and I do worry about this. But… not so much. Been programming since 1982 when I was 10... on a Commodore PET. I was instantly addicted, even though it was a green on black screen, needed to load code on a slow cassette-tape device, and was slow as heck. ;)
You see, in this career you have to be willing to drop everything and learn a new thing. All the time. Make learning new things part of your career.
My strategy is to watch for the “next big thing” and stay at the leading edge of that. 10 years ago, for me, it was the Ruby language, and that has borne much fruit. Now it looks like it’s becoming Elixir, so I’ve been building up a portfolio in that language… just for fun (and maybe profit. Well… Probably profit, down the line.)
Are there 20 to 50 times more Ruby jobs than Elixir jobs right now? Probably. Were there 20 to 50 times more Java jobs than Ruby jobs 10 years ago? Yes. (See where I'm going with this strategy?)
I may not stay as fast as the newest coders, but I will write better code in less time than the guy who writes faster code with more embedded technical debt (which must be paid off in spades, with time, later on), and I’m pretty sure that my ability to mentor others is top-notch, and any good company with 40+ cohorts in management (if also including younger on the front lines) is going to recognize all of that.
I also think that (like it or not… and yep, I struggle with this too) it’s even more important as you age to stay on top of your health… especially in a sedentary job like engineering. It may be a conflating variable here- the demands of family and career (in addition to the effects of age) may add to an engineer’s waistline and double-chin and consequently reduce his “oomph” (or to put it blunter, his T), and ALL of this may contribute to a distaste by the younger teams in hiring the 50+ engineer… Not the age itself, per se, but the impression and deleterious health effects that may typically come along with it. It would be interesting to see statistics which took fitness into consideration.
It may of course seem inappropriate to mention, but the statistics are out there-
I DO NOT condone this (heck, I'm a bit overweight right now and these stats are working against me... I'm just aware of them), I'm just wondering if this is a conflating variable.
To all you budding and early-career engineers- If you're doing it because you love it... Don't worry too much. Just stay on your toes, be willing to learn always, and by all means DO NOT EVER "marry a company." The age of the 30-years-at-one-company committed engineer is DONE. You need to look out for #1. Your career will benefit greatly if you switch jobs every so often... Employers do not have your best interests at heart. Don't believe me? http://www.forbes.com/sites/cameronkeng/2014/06/22/employees...
Lastly, if you're 5+ years into this career, NEVER settle for 2 weeks' vacation to start. It's not only a load of bullshit, it's institutionalized hazing AND it hurts the employer (because you'll be less productive overall for the same pay)! http://www.theatlantic.com/business/archive/2012/08/the-case...
I'm exactly 10 years behind you - started programming computers as a job, i.e. employed, when I was 15 in 1985, and I expect I will be coding until I die. Its the only way I see a future for myself as a developer. That, or learn farming.
What patterns do you see repeating themselves in software? Are there any technologies in particular that you think have a strong grounding in improving on past mistakes or any tech you think is a flash in the pan and has already failed before?
well, it is good that you like the things you do. at your age, we youngsters tend to expect you to be in the management level, not at individual contributor level.
from time to time, i would see our team hiring engineer with gray hair and requiring special mechanical keyboard, and we all thought "mm.. interesting."
Well youngster, you seem to be falling behind the latest trends. Maybe you're not as young as you think. Don't you know all the fashionable programmers/gamers are using mechanical keyboards?
Not all mechanical keyboards are loud or clicky. I use one with Cherry Browns and mostly type without bottoming out the keys, and it's no louder than cheap keyboards.
Ugh, it's so much noise for your neighbor though. I worked next to someone with an old IBM keyboard for a year and was grumpy the entire time. Couldn't find headphones strong enough to cancel out what sounded like someone shooting an automatic weapon in the office.
I think there's a happy medium with the quieter cherry switches. But yeah, I don't use a mechanical keyboard in settings where I'm right next to other people.
The only reason you're not demanding a mechanical keyboard yourself is that you're not old enough to have used one. They have a totally different feel that is more efficient for fast flawless typing. Not by a huge amount, but if you're in a position to specify your tools why would you not choose the best? I'll bet he asked for a big high-resolution monitor too, and you didn't even blink.
Go ahead and aspire to management if you want, but don't assume everybody wants the same as you. And I hope your attitude changes before you achieve it.
Fast touch typist here and I can't say the transition away from mechanical keyboards had any impact on my speed. Shallow travel keys and minimal finger exertion are nice.
I am a "youngster" and I wouldn't mind a 60-years old developer around. Someone who doesn't consider something like Node.js a "new" "technology" and moving code client-side SPA-style a "new" "trend". Even without realising that youth is a temporary state.
The most frustrating thing about it is how hard it is to find knowledgeable people. I went in to the doctor for RSI symptoms that were nothing like carpal tunnel and she insisted I had to have carpal tunnel and started talking about getting surgery to release it within like 5 minutes of us meeting. Perhaps the most galling part of this was where she went "here, let me show you" and had me do the various exercises of holding your hands together that are supposed to lead to tingling if you have CTS and when that didn't work she just said "well anyway, you have carpal tunnel syndrome." Thankfully my physical and occupational therapists were more helpful.
Wow, your experience mirrors mine exactly. Turned out to be a torn ligament.
People wonder why I don't trust doctors, it's not that I don't trust all of them, just most I've dealt with are suspect. There really needs to be a better physician review resource online.
I read some of the literature about RSI and this is a pretty common experience, which certainly does shake your faith in the medical establishment a bit. RSI is not even very rare.
I guess now people think I'm a crank; I posted here that I thought doctors just don't spend enough time with their patients and it's worrying and I was downvoted and mocked pretty hard.
Unfortunately I'm not confident that online resources would allow better decisions. I'm not convinced that patients would, by and large, do a much better job evaluating the quality of their doctors' care. The doctor who just gave patients antibiotics whenever they asked for them, whether or not it was appropriate, would probably be more popular in such a service than the doctor who took the time to understand their condition and explain that that wasn't an appopriate treatment.
Do you also expect engineers to drop like flies as they get older so that their numbers would become more in line with the number of available managerial positions? Cause that sounds like a serious flaw with your thinking.
When I was a young man, a slightly older associate told me that "programming is a trap". What he meant is that if you are relatively smart, you can get a CS degree, get good at it, and go earn a fantastic income right out of school. I heard the words. I understood the words. I agreed with the words. Even now, 30 years later, I keep asking "is this a trap that I choose to remain in?" I still love programming, but it is a trap in that I've not, for a long time, seriously tried doing anything else. So for me it has been 30 years of regular retooling, and likely another 20 years of the same. Unless I decide to open the trap and leave.
You should quit now, and try working a multitude of other jobs. Come back to us and see if your definition of 'trap' has changed, or expanded.
Software engineering is such an entitled world, it is ridiculous. As someone who has seen the world of menial work, I will never, ever leave it. I feel blessed. You should too. You just don't know it.
I guess what I read into that is similar to how you can consider television a "trap". It's easy to get sucked into and not think about anything else. I know that I spend a lot of time thinking about different software related stuff, I love it, but I would suspect (and i could be wrong) that the cashier working at burger king doesn't think about how they can ring things up faster, move between the pickup window and the fries more efficiently while they're playing with their kids, I suspect they go home and thing about their family, not their job, and i think it's easy to fall into the trap of thinking about work much easier when your job is a "thought" job per se.... again I could be crazy though.... good luck if I am.
They may not actually be going home. They may be going to a second job or school, seeing their kids for an hour in the evening, and then going to bed worried about paying bills.
Low-wage jobs are their own cyclical trap, which can lead to not enough resources to improve your situation and apathy towards your day-to-day life. You can easily get stuck in a rut.
I don't think that neither the lawer nor the physician when they get home keep thinking about what their job...
For us coders is different, there was a question like: "What you think while you are coding ?" the majority of the answer was "nothing", the most part of my job is done when I am away from the keyboard, when I walk, dream, read, talk with other people...
I love it, but I am also scared that I am missing a whole word just because I am too focus on computer for a not even too long while...
I am blessed and I do know it. I never said that other careers are more or less "trapping" than mine - I know that for the most part they are not.
My advice to others is the same as yours - quit now and try working in another profession. But it is not to see if their definition of "trapped" will change, but to find out, before it is too late, if there is something they find more rewarding.
I always interpreted my colleagues "trap" statement from long ago not to be about software being career/financially limiting but about satisfaction limiting. Am I coming/rationalizing when I say "I love my work"? I don't know.
It's a ridiculous term which I suppose is supposed to make people feel less guilty about having extremely comfortable, high paying, and overall relatively easy jobs, when they know that millions of others are struggling in jobs they hate, are drastically underpaid, or can't even find jobs.
A common version of this is to complain about a lack of vacation time (even though you have 4 weeks, plus holidays, plus sick time, plus sometimes getting to work from home), as if struggling menial workers barely making above minimum wage are spending half the year in the Bahamas. [Note: this paragraph is written from a US perspective.]
"Golden handcuffs" is a similar term. It's not that there is no validity to these notions or that the phenomenon of golden handcuffs doesn't actually occur, because it most certainly does. It's just that, in their typical usage that I see, these terms are used to invent an abstract struggle that upper middle class people are supposedly facing in order to assuage guilt over their own fortune.
I thought golden handcuffs were typically referring to vesting options in a company.
I know I have friends that don't want to resign themselves to a life of programming/software engineering/whatever you want to call it because they see a ceiling to their compensation, or career path. Theres only so many numbers they can tack on to your title before it becomes meaningless.
I go back and forth on this. There's always a ceiling. For a doctor, banker, corporate lawyer, or salesperson, the ceiling is some multiple higher. But are they better jobs? An MD would require many years of study first, a law degree would burn $100k of your net worth and likely leave you underemployed, you're probably not cut out for sales, and so on.
You really only escape the ceiling going into business for yourself. And there probably has never been a time where it's easier to go into business than the last decade, because of the relatively low cost and high reward of developing software. Maybe that's why programmers are often restless, because the path to wealth seems close at hand (even when it's much harder than it seems, and requires many more skills than just programming).
Exactly. How is this different from any other profession? Developers can be so myopic. The narcissism in our industry really drives me up the wall. The only other industry that is this way, that I've seen, is the entertainment industry. The denizens of which also seem to suffer from this idea that they are totally unique and none of the plebeian hordes can possibly relate to what they go through.
I don't think it's the developers being myopic. For the most part, it's management that views development as a young person's game and encourages people to move out of the technical track and into the management track. If companies viewed programming as a long term career, they would put the pay scales in place to treat it as such. It's only a "trap" in the respect that in many (not all) places your pay maxes out as a programmer faster than it does as a manager. I don't think it's most developer's choice for it to be that way.
I thought this was a problem of managers for the longest time, but recently I read an argument once that convinced me of the opposite.
Tu quoque: the "my boss doesn't understand" problem in companies basically comes from people working for people with lower IQ than them. It's not a skillset gap, it's a pattern-recognition gap.
In the military, the best soldiers become officers, and the best officers become generals—even though these are all different skill-sets—because it's more important to have a good general than to have a good soldier, and so if you could, theoretically, do both tasks well, then the military's comparative advantage in allocating your brainpower is to make you a general.
In tech, we see a "career track" of engineers that attempts to be a meritocracy, with the engineering leads and fellows being the guys who have been there the longest—but that's more like the NCO track of the military, valuing experience for the job they're doing, but not the raw brainpower and tenacity to do jobs well generally. Management, meanwhile, is not-at-all a meritocracy; managers hire from outside based on credentialism, and engineers are "pushed into" management based on credence from fellow devs (the same thing you get from being a battle-tested NCO), rather than being "pulled in" by an actual need.
What military? Most have different requirements for soldiering and officering that don't allow track switching. In modern ones, it's level of schooling, while in older ones it might be nobility of blood. You'd have an extremely hard time even making the argument that going from officer to general is meritocratic in the U.S. right now.
Seems to fit Maslow's hierarchy of needs pretty well. Being a programmer mostly provides for the physiological needs (food and shelter), but it doesn't necessarily offer much else. It's natural and healthy that people also strive for financial security, belonging, esteem, and self-actualization.
I get your point and agree with it. I've said it many times myself. But people don't think in terms of mastering a craft and spending a productive life practicing it. In the modern world if you're not on a trajectory toward the 1% you're losing. In that sense most engineering fields are "traps" because if you stay an engineer you aren't going any further up the ladder. I'm a craftsperson, and I still practice the craft of building software systems professionally, every day, even though I've been doing it for twenty years. That's one thing that hasn't changed. Another thing that hasn't really changed in twenty years is my salary. I understand and accept that, but if you don't know that will be a consequence of being essentially in a trade then I can understand how you might come to feel stuck.
Legacy. Empire. Providing for your children's children. Giving your loved ones the kind of life they've never even considered possible. Seeing the smile on your mother's face when you get to tell her she can stop working, that you've taken care of her and your father, and your brothers and sisters.
The 1% are living in a way that will last longer than they will, on a scale that the rest of us won't achieve in our lifetimes. That's okay, certainly, but to pretend like there's no reason to work towards the 1% is silly.
Maybe you are thinking of the 0.01%. The 1% income threshold in the U.S. is about $380K. That's wealthy but it's not empire-building. Most senior software engineers are probably in the top 5% of income earners in the U.S. already, they could easily be in the top 1% with a high earning spouse.
> The 1% income threshold in the U.S. is about $380K.
It's $521,411 per household[0] (the household bit is probably where we're getting confused).
$500k, $400k, either way, the goal is as I've stated; once you've taken care of yourself, you start wanting to take care of others. There is always motivation to make more, until everyone is provided for, and even when you've provided for everyone you care about, providing for the general wellbeing of humanity becomes a priority (Gates, Buffet, et al).
'My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!'
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away.
One possible explanation for that is that there are two kind of people, some who believe that everybody is working towards the same goal and some who believe that everybody should decide what their own individual goals are. The former group settle on money and social status as those universal goals, because they are reasonably common and can often (though not always) be exchanged for what you really want. The latter don't believe in telling other people what their personal goals are, because if they are different for every person, what's the point?
Under this model, 100% of the public discourse would be devoted towards achieving money and status. That does not mean that everybody (or even a majority of people) pursue those goals, only that people who do talk about it a whole lot more than people who don't.
I imagine any career path you specialize in can be considered a trap. The more time you invest in, the more it feels like you have to stick with that path so that time doesn't get wasted.
My friend who was a plumber recognized this. He also realised that plumbing is not something that you want to be trapped in. As you age it get's harder and harder to be constantly crouching down and contorting yourself into those hard to reach areas. So he jumped ship and is retraining as an architect.
Programming doesn't have that limitation. Barring the odd bit of RSI there is nothing to stop you coding until the day you drop.
Right out of college, I joined a startup and I learned alot. Then I joined a huge financial corporate company as a senior developer and find myself moving into more and more management roles. Having been in both worlds, I conclude that management is a trap, especially in your twenties and thirties.
the fuck! This is like someone telling you your fiancée is a trap, because she is amazing and perfect for you, you have everything in common and you will end up happy and together forever. like a black hole of perfect happiness - you'd better turn away before you're past the event horizon. Odd advice to say the least. :)
I believe he implied the income was great, not that you would continue to enjoy the work, so it was hard to pivot into less-technical fields even if you wanted to.
I like software, but for instance, I really couldn't make the same as a photographer (plus, I don't want to shoot weddings or people or stock photos and stuff...).
However there are some great examples of stock traders becoming potters and things like that, so it CAN be done, you just have to change what things you are addicted to - or earn a bunch first :)
Do you mean it as a trap financially speaking? e.g. after certain age your salary stagnates, and your 'hireability' is reduced dramaticlly (ageism comes to mind). If so, I agree that might be true in some cases (anecdotically speaking), but not only for programming. But if you love it, what is the non financial cost of 'leaving the trap'? Isn't the real trap not improving/advancing in the things that really matter to you, because of things you can't or are very hard to control?
I think that I understand. Programming is a trap because it is easy to be satisfied with writing code. It is fun and rewarding. But it may not be the most valuable thing you could be doing for your organization or for your career.
Yes. Thank you for understanding my use of the term "trap". My solution this week was to purchase a mandolin and start learning to play an instrument. Not so much a "trap release" as an "escape valve".
As someone who started programming during the mid 80's:
- Everything I've learned may be applied to most languages. Meaning that writing testable code generally translates from BASIC to Javascript.
- Programming should always make you feel stupid. Feeling comfortable with something means that you stopped learning new things.
- Experience != Knowledge. My biggest issue with some older programmers is that they tend to confuse experience with a language, codebase, or framework with knowledge. The more you learn the less experience you will have. Think about it. You start learning Javascript after years of working with C#. What does that experience work for now? You will surely have an understanding of all the basics. But you have not yet been bitten by the == and === operators. You have to get that new experience. As time passes you will realize that it becomes a game of knowing enough versus being experienced enough.
- New technologies are exciting. A lot of people are scared by them. They feel they will be replaced. Their comfy jobs taken away. I'm not scared of this. Change is exciting because it means that I will have the chance to learn something.
- New languages might be rehashed versions of older ones. But they contain something different: Somebody else did it. That's reason enough to give it a try. Javascript might not be the most universally praised language, and it doesn't really bring much new to the scene. Its still someones interpretation of how a given problem should be solved. You might not agree with it, but that wont stop people from writing lots of JS code.
- Nostalgia is fine. Don't let it get you. Sure, I miss typing BASIC into my old C64, but its no longer relevant. I could pick up demo'ing as a hobby and learn lots of stuff about old chips and memory management tricks. It wont really help me to stay employed much.
- All these new devices are scary! I grew up programming for one kind of device. Now I have to take into account tablets, phones, tvs, and whatnot. Embrace it. Mobile is here to stay. It will keep morphing and completely remove desktop computing as we know it. The same way desktop computers removed mainframes and terminals. It is scary. Try and get excited. There is nothing more mind blowing than watching a several months old child tap on a tablet to play a game.
Mobile devices will presumably jack in to large monitors or head mounted displays of some kind, plus a good keyboard of some kind, and pointing device(track pad). Thanks to Moores law you should be able to have the equivalent of a desktop experience driven by a mobile device soon.
The one problem is being slave to Apple and Google having absolute control of the OS, software and apps you can run. The only plus is their hegemony does help with security but neither one of them is even remotely trustable with the keys to every personal computer on the planet. There is irony that the creator of the big brother commercial in 1984 is increasingly, you know, big brother.
P.S.
Not sure how Daves self promotion blogging rose so far on hacker news. It actually has almost nothing to do with Doug Engelbart. He was just name dropping, something he often does, before doing what he usually does, self promotion. Yes there is that age discrimination angle which plays well with some old programmers, but not me.
People who spend their time complaining about discrimination should spend more time doing something that people will value regardless of your age, sex or gender. At that point your age, sex and gender become irrelevent especially on the Internet which tends to be blind to these things until you wear them on your sleeve. Dave likes to use his age to promote a martyr complex angle.
Ive looked at most of Daves recent projects and none of them are particularly interesting.
Do you happen to have a TV? A fine large display for most folks.
For pros (programmers) there will continue to exist dedicated large displays, pro keyboards and whatever else. Look at professional gear of audio or video engineers, or CAD users, they have pretty impressive devices to use with computers. It's just not what mass users have at home.
Fully offline desktop computing will remain possible, much like running a C64 or an MSX machine (possibly in a form of new, much cooler hardware) remains possible. It's just not very relevant.
They don't, but they're actually not bad analogues for the computing experience we had a couple decades ago. The original 128K Mac (https://en.wikipedia.org/wiki/Macintosh_128K) had a 9" display, after all -- not that much smaller than the display you get on an iPad Air. I bet someone who learned how to develop great UIs on those Macs would be right at home doing the same on a smartphone or tablet.
Me too. Just give it a bit if time. When some yet to be born kid realizes how dumb and wasteful the cloud is (their words, not mine) and comes up with whatever it is that will replace them. Just like those meddling kids came up with that thing that allows me to type this post without a physical keyboard.
It's not so simple, if you look from first principles. It will always depend on the cost of communicating versus the benefits of economies of scale in computing. Currently, most many can only be done in the cloud due to the massive scale benefits and relatively low communication costs. If communicating doesn't get cheaper but smartphones get massively more powerful and roomy overnight this might change; but it is a fact of computer science that there are economies of scale to lumping queries from different users.
> Mobile is here to stay. It will keep morphing and completely remove desktop computing as we know it. The same way desktop computers removed mainframes and terminals.
We've largely circled back to the mainframe/terminal model, except with a prettier face. Your mobile device is the terminal, and the server cloud is the mainframe.
"Unlike Engelbart, I have re-tooled. I now work in JavaScript in the browser and on the server. I had to walk away from the codebase that I loved. I understood that the price of relevance is to give up fighting at some point and settle for a partial victory. I think I was right in the development environment I created. But right doesn't mean the world uses what you created."
Yep. That's the key to staying relevant: change with the times.
For me, the thing that gets a bit discouraging at times is the feeling of riding a slow-motion merry-go-round. Every 10 years or so you see the same ideas start to come around again, only with some new paint and landscaping.
I have found myself more than once thinking that learning about some new trendy buzzword is just ultimately a waste of time, since I will barely have mastered it before it's been replaced by the next new/old thing.
On the other hand, it gets easier since none of the concepts are new anymore, and I tell myself, "hey, if you want to pay me to build a client-server app in the browser like it was 1995 (substitute Powerbuilder for Firefox/Chrome), great, happy to take your money."
I see the same thing, but feel much more optimistic about it: it's not, in my mind, that tech is effectively fashion, but rather that there are "futurist" ideas that tech keeps trying and which keep not getting adoption, because it's not their time yet—the state of the art isn't there to make the experience for the average consumer (or the average developer) justify the costs.
An example of what I mean: the Apple Newton, and then 10 years later the Palm Pilot, and then 10 years later Windows CE and flip-phones supporting J2ME, and then 10 years later touchscreen phones and tablets. There have been four generations of "mobile app developers", but only the latest generation has seen any traction for their apps. This time the idea stuck; it will stay around, rather than coming around again.
If something like Paypal's prototype service (beaming money from one Palm Pilot to another) were set in this "revolution" of mobile instead of that one, it would be much more successful.
And you hopefully have learnt from the mistakes Powerbuilder did back in '95, not making them again. So in theory you're ahead of the crowd of today.
Though that means that you have acknowledge that things were not all that great back then as you remember - which seems to get harder as one grows older.
I don't see that at all. I started out when "structured programming" and "recursion" were both exciting concepts. OO came along and over a ten year period went from "useful for UI" to "the One Ring To Rule Them All" and while the shine wore off a bit, it really did help.
Today Functional Programming is introducing all kinds of new ideas and approaches, and while I often find FP people over-earnest and irritating, I'm still able to recognize that they offer something new, even if it isn't all they think it is.
Impure functional languages like Haskell have shown that it's possible to get many of the advantages of a purely functional language while still being able to implement side-effects, which is an amazingly cool trick despite Haskeller's annoying insistance that their side-effect-ful "language" is "purely functional" even if they have to redefine "language" to make it true.
This is true of all the supposedly "pure" functional languages, which universally come with caveats that amount to "disregarding all the sex I've had, I am a virgin", but that's just a somewhat off-putting quirk of the community. The languages themselves are full of interesting ideas that are being adopted by less purity-obsessed languages, and this is a good thing in the same way that the OO-purism of SmallTalk drove other more mainstream languages to adopt OO ideas and bring them in adulterated form to the unwashed masses (which had the nice side-effect of driving the purists nuts, and who doesn't want to see that?)
So I personally get the feeling that it's a great time to be alive and active as a software developer. We're barely out of the "bash rocks together to make hammer-like-thing" era of programming, and we get to be part of the most explosive growth phase of the most important technological growth curve in human history: the algorithmization of work.
Most companies aren't using the trendy new languages and tools. The bulk of jobs today are for C++ ('83), Java ('95), Javascript ('95), Python ('91), and maybe C# (2000).
It's a shame, too, since C++14 is a far cry from 1983's C++ (or whatever version the majority of the segment of the industry which uses C++ is actually using), and the others are similar stories.
One the one hand, I suspect ams6110 was referring more to those things we give names like "pattern," "architecture," and "paradigm," maybe even "stack," "platform," or "library" than to languages. On the other, my suspicion may be wrong, and I'd agree with him about it if it were anyway; so little that's been developed in the world of programming languages recently is anything new, and what isn't is as often as not a poor reimagining of something Lisp or ML had figured out pretty damn well ages ago, thank you very much.
Still, though, progress has been made even on the mainstays, even if the industry hasn't quite caught on yet.
C++ dumping ten pages of unreadable error messages on you because you forgot a semicolon or misspelled an import? If that is C++14, I'd hate to see 1983's version.
As a young person my biggest concern with hiring old people is that exact attitude: this is just like $IRRELEVANT_OLD_TECH.
Yeah on the surface. $IRRELEVANT_OLD_TECH didn't catch on or it wouldn't be irrelevant but _why_ didn't it catch on? Powerbuilder failed, but was it because you couldn't write a good enough program that way on 1995s hardware? Or because it was ultimately a stupid idea?
Somebody like me who has never heard of Powerbuilder would have to look into the technology, which would take longer but it would prevent me from just dismissing it because "this has been done before".
Remember it isn't what you don't know that gets you, it is what you know for damn sure that just isn't so.
I am not saying this is the case for all old developers, but it would be my concern.
Yeah on the surface. $IRRELEVANT_OLD_TECH didn't catch on or it wouldn't be irrelevant but _why_ didn't it catch on?...
I'm a young person, too. Lipstick on a pig doesn't make a cow, you know.
Arguments like "It's only similar on the surface" I've found tend to give too much credence to incidental properties - this runs on X, it's widespread unlike previous solutions, it's better at specific Y use case, etc. Yet regardless of underlying platform, the concepts do not tend to evolve quickly, and it is all too often the case that their limitations have been discovered either in academia or engineering practice. These limitations will eventually be uncovered again, and no one learns from their failures or successes. Where languages and platforms shift, architecture will always bite you.
As for the reasons why, that's another fallacy. It assumes the status quo always maintains an equilibrium of what is inherently technical superior, and that popularity implies great technical qualities. The reasons can be plentiful, often it's unfortunate historical circumstances.
> As a young person my biggest concern with hiring old people is that exact attitude: this is just like $IRRELEVANT_OLD_TECH.
Leaving aside the (substantial) ageism issues here, it looks to me like your reading of the GP's complaint is incorrect.
It's not a judgment that $NEW_TECH is going to not catch on or otherwise fail because it's just like $NOW_IRRELEVANT_OLD_TECH.
It's the observation that much of the $NEW_TECH that catches on and succeeds for a time often turns out to offer approximately the same utility as $NOW_IRRELEVANT_OLD_TECH... and similar adoption costs, which we pay over and over again. We rent rather than buy.
There are counterexamples I can think of -- new tools/abstractions/practices I've adopted that have resulted in near order-of-magnitude gains. But the ratio of these to other $NEW_TECH that just sort of shuffles the dirt around... well, that probably approaches another order-of-magnitude relationship.
And there's also the argument about the aggregation of marginal gains (see Brailsford and the British cycling team); approximately the same utility isn't quite the same thing as exactly the same utility and I don't think that should be overlooked. In fact, I think one could put together a specific case that the GP is arguably not correct in making an even comparison between Powerbuilder and webapps on precisely such a basis.
Still, an aggregation of marginal gains approach only ends up helpful if the marginal and opportunity costs are low.
How often do you find that's true for $NEW_TECH over $NOW_IRRELEVANT_OLD_TECH?
And since we're being free with judgments about age here (generalizations, naturally -- not that you or I would ever let such general thinking affect our judgment when it comes to individuals)... do most young developers really have enough knowledge and experience to answer that question effectively?
"There are counterexamples I can think of -- new tools/abstractions/practices I've adopted that have resulted in near order-of-magnitude gains. But the ratio of these to other $NEW_TECH that just sort of shuffles the dirt around... well, that probably approaches another order-of-magnitude relationship."
Further, most people seem to have little appreciation of the difference between order-of-magnitude gains and shuffling the dirt around. Certainly, there are those who are wrong in assuming anything new is just dirt-shuffling, but for anyone without experience, everything offers an order of magnitude. And this really is an engineering discipline---$NEW_TECH is never as good as its proponents say, but it the best trade off in some circumstances, while $OLD_TECH is never as bad (or good) as the "general consensus" would have you believe, while it is almost certainly inappropriate under some scenarios.
Something I've found as I've gotten older, though, is that I have a stronger and stronger sense of wasted time every time I have to learn a new way of doing the same thing. Particularly if the new way involves a bleeding edge leaky abstraction.
Because every hour I spend investing in a new stack and its details is an hour I can't spend thinking about product-level details, can't spend learning more learning about organizational-level matters, can't spend on improving more timeless investments like statistics, math, and soft/interpersonal skills. Not to mention fun things like music and travel and enjoying the company of people you like.
It wouldn't be so bad if most of the new shiny things in the software world were an order of magnitude better. But saying that 1/4 new frameworks or even languages present tha kind of power/productivity jump would be optimistic.
That is one of my biggest concerns. A lot of the new tools are just different, not better. But you're expected to know all of them.
It's also hard to predict what will be popular five years from now. I thought that using Javascript on the server was pants-on-head retarded, but it's very popular, with no signs of passing on.
Generally sound, but there does seem to be a certain breed of vanguard who lives off being heterodox with regards to the computing mainstream, yet functions just fine and likely harbors plenty of insights. Much of the Go team lived full time on Plan 9 at one point or another, and it's not like all of them were Rob Pike or Ken Thompson.
There is value in keeping up with trends, but on the flip side there is value in sticking with sound ideas, even if they are not necessarily attractive in the labor market, and learn enough to be employable or self-sustainable in some regard.
I would say server-side JS might not necessarily be a great long-term prospect, at least in part due to limitations with SMP and unwieldy concurrency models. Even if it persists, the value of knowing might be more of a labor necessity than any inherent utility.
Because programming operates on lots of trends and conjecture, knowing which ones not to waste time on is a much more valuable skill than jumping to stay "relevant".
I think I'm coming to grasps with this too. I'm over 30 and have spent most of my life building large desktop applications in C/C++. I want to eventually work remote, and looking at what's out there, there are very few opportunities with someone with my skillset. It's all modern frameworks and languages. So, I'm spending some of my own time learning some of this stuff.
Embedded programming is also harder to do remotely due to needing hands-on access to development hardware, frequent access to hardware engineers, expensive test equipment, and so forth.
I worked as a C and then C++ dev for a few years and then I started a Ph.D writing a C++ code base.
I remember the day that I got java 0.7 running on my spark 20. I would never touch the STL again, never have to worry about malloc and #def overwrites. No more gdb.
It's also a silo that can be hard to get out of and is very hard to get into, because all you do is C or C++ work and everyone wants C or C++ experts for their jobs.
This. I see too many older developers who complain about ageism, but what's really going on is that they're essentially the same developer they were 2-3 years into their career. If you've been working in the industry for over 20 years, employers can and should expect that you've made the most of it. Those developers have very few problems with ageism. It's the ones that have become comfortable and stagnated that have trouble.
I'm not a programmer anymore, so I don't have a horse in this race, but I cringe when people exhort older programmers to "stay current."
If you're spending your free time learning about distributed databases, machine learning, cryptography--fields that existed in the 1990's but are more relevant and developed today because of the web--you're becoming a better programmer. If you're figuring out the latest "compile to JS" language or framework, you're wasting your time. You could do all that stuff in C++ or Lisp or ML. In 1994.
Maybe there are lots of programmers who don't stay current. But I also think there are lots of employers who can't distinguish between "staying current" and "keeping up with fashion."
I am in the middle of these two groups. Often "Stay current", "It's different with modern ideas/methods", etc... Expressions commonly used by people who want to ignore the lessons that other people had to learn the hard way. Ironically claiming they claim the old person is out of touch. When in reality they are trying to prevent newbies from repeating the past.
When I'm interviewing a developer, I'm less concerned with what they've been learning and more concerned with if they've been learning. As long as you've accepted that being a developer means constant change and constantly learning, you'll be able to make up your own mind about whether new fad X is worthwhile or whether your organization should skip it. But if you get to the point where you stop learning, you'll be stuck with a certain set of tools/skills that eventually stop becoming adaptable.
I like to think of it like evolution. Most mutations are not advantageous and die off quickly. The ones that are allow you to outcompete competitors. I've learned 3 new languages this year, toyed with 2 new data stores, and played with/read about countless frameworks and libraries. Most of these technologies took up less than an hour of my time. Some I devoted a half day of hacking with. Others I stuck with for longer. From all of this, I've filtered it down to a handful of tools that I'd consider using in specific situations. This is what I consider staying current. I consider this to be between 10% and 20% of my job as a leader in my engineering org. And it's what I feel that I need to do so that when it's decided that we need to use something other than what we're using now, I feel that I can come up to speed on that new technology quickly.
It gets frustrating interviewing developers who, for the past 20 years, have programmed nothing but Java. Sure, they know a few libraries within the Java ecosystem but, for the most part, all their learning from the past decade was domain-specific knowledge from their last job. And then they want to be rewarded for that "experience" at a new employer. Sorry, that's not going to happen. I can hire a newly-graduated university hire who's more willing and able to put in the time to learn for half what I'd have to pay you. That's not ageism, that's common sense. On the other hand, when I encounter a developer with 20 years experience under their belt that has used that time wisely and has enough tools in their utility belt to make Batman jealous, I'm more than willing to bring them on and pay them accordingly. They'll be a great mentor to all the younger hires I'm forced to make.
The key point of contention that I have with you is that I don't consider time spent learning to be wasted. Ever. Learning itself is a skill that needs to be practiced, even if that means learning something that you'll never use.
One could also argue that it's better to interpret "stay current" as being about "learn new frameworks", but rather "learn important concepts and their applications."
One can write object oriented code (with clear modules and interfaces) in plain-old-C (see "C Interfaces and Implementations"), just as one can write Fortran in Ruby (and I don't mean by creating a DSL sensitive to positions of characters in a line).
If we look at the market adoption curve (Marketing 101) most of the money and most of the demand is in "old" technology. But extremely old tech, extremely new tech, either way there's going to be demand across the spectrum relative to the supply of developers.
Unfortunately for non-fad followers, the people with money want to use the fads.
Shouldn't having the knowledge of what you could do in 1994 make you that much better suited to doing it in 2015 even if you have to spend a few days learning the faddish way of expressing the concepts?
The point isn't that you can insulate yourself from the fads; the point is that you should spend your career-building time on fundamental skills acquisition, and pick up faddish frameworks and languages on a JIT basis. People who can write compilers generally aren't too intimidated by compile-to-JS languages.
I am 57 and quite current. I have launched several startups and kept fresh constantly. My current client has me doing lots of leading edge stuff that some of their younger devs couldn't do.
And yet I do feel the ageism. I understand it and I'm not angry about it, but it's real, nonetheless. It's not a good feeling.
Someone with 10 years of experience, unable to recognize the nuances one picks up by repeating those 10 years of experience with 10 years of context to make better sense of it.
I'm 37. I think ageism is a very real problem and I hope people will consider doing more suing even if they don't have to. Some people need to be sued. We need some class actions.
Right from the top down of Silicon Valley ageism is rampant and in your face. For example, Sam Altman has publicly made explicitly agist remarks.
You kids may not think its a big deal now but give it ten years or so. You will see.
Of course in 10-15 years everyone will be in the same boat, being completely ignored by the ASIs.
"Of course in 10-15 years everyone will be in the same boat, being completely ignored by the ASIs"
Exactly, so why give them any credence now?? You only give these people power if you do. That's great that's what Sam Altman thinks; he's "young", but ya know, when he's 50, then what? He'll probably say "oh, that's obviously not how I see things now". Or Zuck. He's ancient to a 19yr old and the only reason he doesn't care about this is because he's rich and runs Facebook.
I'm older than you and have been through enough startups and honestly I've dealt with ageism enough to the point that it doesn't even phase me anymore - I've moved past it. But this is because I've made it that way. If people don't want to work with me, np, there are plenty of other opportunities out there.
Sure, you might not get hired at the hot startup you just interviewed at. But honestly, if that's the case, who cares? Make your own way, your own rules and then you can decide to hire young or older people or not.
Anyone interested in Doug Engelbart and his pioneering work at Stanford Research Institute (or computers in general) should check out What the Dormouse Said: How the Sixties Counterculture Shaped the Personal Computer Industry [0]. It goes back much further than Xerox or Apple to tell the tale of Engelbart's visionary Augment project and how his ideas led to the birth of the PC and the internet.
If you're not interested in purchasing the book, he gave an incredible hour and a half long demonstration of his system at the Fall Joint Computer Conference. Dubbed The Mother of All Demos [1], he displayed (for the first time in the world) remote video conferencing, hypertext, text editing, and a graphical windowing system. In 1968. Definitely worth a watch.
Interesting, I just hired someone in mid 50's for a programming role. We've seen at least a dozen candidates and he did by far the best on the phone and code test. Now I'm happy to have him on the team. In a industry with a shortage of people that are good I'm surprised anyone can afford to discriminate good candidates based on their age. I think the key is being good and getting along with people. I've interviewed some older guys that were not only bad but were coming with an attitude that they were going to teach everyone here.
I was looking at some of the code for one of his projects that is a little node http server. I don't really know JS or node at all, but can someone explain this to me:
function secondsSince (when) {
var now = new Date ();
when = new Date (when);
return ((now - when) / 1000);
}
I'm assuming now returns seconds since some fixed point in time ( epoch ) when when someone passes in the 'when' argument, it must already be formatted a certain way, or node/js somehow managed to figure out the input? How would it deal with 5/8/2015 vs 8/5/2015
Or this is just a very case specific function and the input is already sanitized in a way that is prepared for this function?
new Date () returns creates a JavaScript date object.
When coerced to a number, it's the number of milliseconds since January 1, 1970.
If you wanted to know the number of seconds since January 1, 1970, you could divide by 1000. Since JavaScript will do the coercion for you automatically you can pretty much treat a date object as if it were a number.
This is basically a utility routine that I use for debugging messages to say how long an operation took.
I'm not 100% sure what he's doing here, however I know when I have used new Date().getTime() it returns something like milliseconds, and thus I had to divide by 1000 to result in seconds, so it appears that he's subtracting milliseconds and getting seconds after the division by 1000.
Also assuming I can read, it doesn't look like that function is used, (I searched second in the same file, and in the higher level folder, and couldn't find that function called anywhere)
a Date can be constructed with either a number of milliseconds since the epoch or a string in a format recognised by the Date.parse() method (IETF-compliant RFC 2822 timestamps and also a version of ISO8601)
The more interesting post was the link to Phil G's blog post about the MIT reunion:
"The medical doctor was at the peak of his career and in no danger of being fired. The university professor had the security of tenure and was looking forward to a defined benefit pension starting six years from now. The corporate attorney was finishing up a prosperous career. The engineers who’d chosen to work in industry, however, were a varied lot. A woman who’d taken a job at a defense contractor was still there, 30 years later. The super-wizard Lisp Machine programmer was now in a senior technical, but non-supervisory role, at a multi-billion dollar dotcom (not necessarily getting paid more than a competent 30-year-old, however). About half of the engineers, however, talked about being pushed into a financially uncomfortable early retirement and/or not being able to find work."
So far, it looks like nobody is commenting on Dave Winer’s own work.
Everybody has been influenced by Engelbart, but nobody uses NLS. Merely the ideas went into all the computers that we use today. Engelbart was so frustrated because he had more great ideas, but they were difficult to develop and he couldn’t get funding.
Winer specifically mentions Userland Frontier. It was a useful tool, which I’m sure helped with the development of RSS, just as NeXT Project Builder helped with the development of WWW. The problem with the Engelbart comparison is that there are countless other development environments, many of them free and/or not in a dialect of C and/or available via git, while the Mother of All Demos was unique.
I think the open-sourcing of Frontier was too little, too late. Frontier is an impressive achievement, but I don’t see why it should be interesting to me.
I play a lot of music with folks older than me... I'm 37, and the drummer in a blues band I play with is 73 (he's a neat guy- he was in the 13th Floor Elevators).
I've played with folks in their late 80s, and most of the folks I play with weekly in a large jazz band are between 50 and 70. I also play bi-weekly with an orchestra with members ranging from 12-82.
Maybe I lack the same perspective I lacked when I was younger (and thought that 45 was pretty old), but I absolutely don't see how 60 is old. 80 is old, maybe, but 60 just isn't that old, and I don't mean that in the attitude sense, as with:
"The ones that love me say I'm really young, and I appreciate that. I think they mean my thinking is flexible, and I'm excited about the future, like a young person might be."
You wonder why people aren't curious?? I'm 28 and I would pay money to spend a day talking about coding with you - I'm "senior level" at my company but that just means I don't have very many people around to mentor me. If you're near the Seattle area I'd love to buy you coffee.
This is a great thread. What I have appreciated most is seeing the long-term vision that older programmers have - thinking in terms of change over decades, not years.
Working in the web industry, the second-hardest thing I find (after pace of change/fascination with "New! Shiny!") is the vision of people can be measured in months to 3-4 years. Applications are not built with the thought they will be running in a decade; it's assumed they'll be rewritten in New Language X with New Architecture Y long before that.
To older programmers: if you work in the web field, how do you handle/deal with this?
Not that I condone treachery, but growing up my father used to have a famous line "Old age and treachery will beat out youth and enthusiasm any day". And although he wasn't a programmer, but rather an investigative thinker, his subtle manner of obtaining voluntary compliance seemed to win the day. Whilst not treachery in the blatant sense, there was allot to learn from this wisdom which is only gained from life experience. Would I have hired Doug, probably, but I think maybe I would have been better self-served being HIRED by Doug. My age - 43 and irrelevant IMO.
Part of the problem, at least in America is one that people don't want to talk about. The industry has globalized greatly over the last couple decades, and many companies hire in areas that have no labor standards. Companies are operating under US labor standards but are hiring people in greater numbers in China and India, some to work in the US. In those places discrimination by age is commonplace. Additionally, there are a large number of foreign managers working in the US who don't understand why they can't just openly discriminate by whatever standard they want. and it makes sense they are confused if you're allowed to discriminate in some cases but not others at the same company. No one regulates US based corporations hiring people in overseas markets for US jobs. The problem is so bad that many resumes that US managers in US companies have sitting on their desk contain things like age, birthplace, country of origin, family members, and even blood type. It blatantly violates US law.
"The processes I use, investing in good tools and underpinnings, and paying attention to good features of other people's software, makes it easy and quick to try out new ideas. Some of them are really worth it."
What processes is he using? What tools and underpinnings that allow him to quickly try out new ideas?
I read an article recently that said something to the effect that most people stop listening to new music at age 33. I kinda feel the same about programming. There are a lot of people still doing it, but not as many that are truly excited about learning new things.
When we bring on young people they have a ton of energy and are excited to try every new thing which, don't get me wrong, is awesome. But they do occasionally criticize me for moving too cautiously, even though I am plenty excited about trying new things. I always think to myself, call me back in about 15 years and we'll see whether you evolve into the rockstar that you envision yourself to be, or else if you stagnate, burn out, move onto something else, etc. I always hope they do become the rockstar.
I am 45 and I almost only listen to new music. I have almost a 1000 CDs from the 90s and early 00s (all ripped to FLAC), but I find myself listening to new music because there is so much fantastic new music out there and it is so easy to access. For a music fan it really is the golden age (not so much for the musicians).
As for learning new programming skills I still enjoy it, but I think this is because for me languages/frameworks/algorithms are just tools. The real fun is in using the right tool to solve a complex problem.
Same here. I basically get bored with most music fairly quickly so I'm always looking for something new. Most of my high-school friends are still listening to the same music from the 80's and 90's though!
I'm 18 years old and I just got my first significant programming job building android applications for a medical device company. I must say its inspiring to read something like this. I've heard stories from mentors and professors about what it takes to stay relevent in the field computer science. It's odd to think that the technologies I've devoted my time and energy could be all but useless by the time I turn 30. Maybe it's wrong, but I dream of a post Moore's Law era where development tools can finally mature and the best programmers are the ones with 40 years of experience.
I can imagine a time in my distant future where I will feel unappreciated and/or unable to keep up with technology the way I can today (though admittedly even today it's not an easy task given the trajectory. I'm pretty certain we're on an exponential curve).
What is the gift that will keep on giving? Write about what you know. Write about your experiences and insights. Even thousands of years from now people may come across your work and given the advances they will be living amongst will almost certainly be interested in what you had to say.
I'm 30 and a senior programmer. What should I be doing to ensure I have career options at 50? Is management inevitable with individual contribution primarily reserved for scrappy youngsters?
I think this goes without saying: never stop learning.
The people that are resourceful will always find a way. Sometimes this may mean on your own, sometimes with a group. But as long as you can keep learning and just 'do things', you will be light years ahead of those that don't know what to do and look to other people to tell them.
From Steve Jobs:
"Everything around you that you call life was made up by people that were no smarter than you and you can change it, you can influence it, you can build your own things that other people can use."
It's hard sometimes (a lot of the time??) to get over that bit where 'no one is smarter than you'. (I'm not as smart as a Google PhD, am I??..) Once you can and you chart your own course because you are resourceful and confident and someone who can do things, then you won't need to ask the question you asked. :)
I would say there are generally a couple options:
1. Yes, first is straight-forward dev management.
2. I would say another option related to #1 is to go into PRODUCT management, which can then lead to higher level product responsibilities. Someone who is a great product manager who ALSO has a deep technological understanding of implementation options is a real rarity and extremely valuable in today's job market.
3. If you do want to be spending the majority of your time writing code at 50, you need to do everything you can to be a complete expert in some technology. You'll need to change with the times as that technology evolves and pick up new skills, but lots of technologies have lifespans longer than we may think. For example, Java has been around for 20 years already, C++ for over 30, and there is still loads of running technology that uses these languages.
I'm 30 now (from time to time I feel that I've already lived enough and am mostly done), the idea of expecting at least 30 productive years ahead of me is intriguing.
What have you done that makes you feel satisfied with your life? Just curious. I'm 37 and feel like I'm just getting started. Keep in mind that I have wasted very little time. Always working on some project here or there. Right now I'm planning my next fourty years. So it really makes me wonder how you can feel you are done.
I am right there with you. I am a little over half way through my 30th year of life. I have "wasted" a lot by having a ton of fun and enjoying myself, while also getting plenty done professionally. I am excited about the future, and also intrigued with this concept of another 30-50 years of productivity, but like you, sometimes I can accept a fate of being 'finished'. It's weird, but not in a morbid way, more like a, "I'm so blessed to have been able to do all this amazing stuff" kind of way.
> I'm 30 now (from time to time I feel that I've already lived enough and am mostly done)
This is the most absurd sentence I've read in weeks. Wow, man. Talk to some people a bit older than you, maybe, and realize that you haven't done anything.
Yeah; totally! You're only 30 and already happy with your life!? That's way too fast dude! You really need to feel incomplete and unsatisfied for at least a decade or two more! /s
One of my mentors is in his 60s (I think). He's an extremely successful architect/consultant who still does plenty of coding. His enthusiasm is what energizes me (just turned 30).
I'm not saying that people don't get tired/slower as they get older (I struggle with it), but I don't think it's inevitable.
