I'm 64 and retired last year. I spent 4 decades programming, and everything changes all the time, and I always learned new things. I am still learning new things, and still writing code to support my generative art. Admittedly I was finally burned out of the grind of working as a programmer, but it took a whole lifetime. But to truly approach new things you have to be willing to let go of the old, even programming if necessary, but without forgetting what you learned. A lifetime is a long time; you really don't need to just do one thing the whole time.
A quote from a novel has always been an inspiration since I read it in high school - "An artist must leave a body of work" from The Agony And The Ecstasy, about Michelangelo. If your programming no longer excites you, learn something new in programming, or even learn something that isn't programming and do that. It's not easy, and might cost you money, but wasting your life doing something you no longer care about is not worth it.
Of course some people can deal with a terrible job, and just spend the non-working time doing what they love, and that's OK if you can deal with it. I could never do that; I didn't turn to art until the last few years.
I'm just over 50 and I'm finding it harder to stay in programming.
Most companies want to push me upward into management (which I don't want to do) - and I feel like I'm aging out of eligibility for most development jobs.
How did you manage to stick with it? I still love it.
Learn, learn, learn. Find the new hotness (at least one that has staying power).
For me, kubernetes is the latest 'big hill'. It seems to have legs for years ahead, and plenty of technical details that prevent anyone from completely mastering it.
58 in a few weeks, and seriously considering going the other way: To jump off the treadmill of new fads and concentrate on / return to basics.
"Big Data!" "Data Lake!" Data Vault!" "Apache Spark!" "Kafka!" "Cloud this!" "Cloud that!" "Cloud the other!""Snowflake!" "R!" "Python!" "Pandas!" "This new ETL tool!" "That new ETL process!" "This other new ETL tool!" "That other new ETL process!"...
Sigh.
SQL and bash ain't going anywhere, and they're all you really need for ETL.
I'm thinking of really learning the old cool in stead.
When I was just starting out (circa 1990) a good friend of mine had a pal that was making his living servicing punch card machines.
They were completely unsupported by IBM at the time, this guy had been an IBM tech and saw the opening. He embraced the old tech, knowing there were people still using it and willing to pay for some form of support.
So I don't disagree with that idea, it's definitely workable.
Anecdata: was asked by a client why the same query was running orders slower on our infrastructure (IaaS on Xeons) than on their test server (a regular desktop with i7). I check the load, IO, yada-yada and I don't see anything what could indicate the slowness. After a bit I check the db size and ... I'm pretty speechless, because it is 77MBs. 77 megabytes and the query runs for tens of seconds. I tell the client to give me the query. They are happily oblige and provide a two FullHD screens of SQL with like... 20? More? 'SELECT *' from the same tables on and on.
After speaking nicely with the client about the origins of this query and checking their dev environment, I learned:
1. this query was autogenerated by Lavarel
2. their dev environment is 100 times smaller than the prod
3. until I forced them to copy prod data to dev they didn't believe the problem was with the query
4. between two programmers and one sysadmin on the client side NOBODY was even close to reasons of slowness.
So... for some people SQL in 2022 is pretty equal to punchcards.
My first dev job about 15 years ago I took over this in-house developed intranet. Some queries took quite long (30 to 60 seconds), and according to "the last guy" there wasn't any way to speed it up. At the time I didn't know anything about SQL (literally never used it before), but I figured there really had to be some way to do this faster. I just read some basic documentation, rewrote a few queries, and now I got the exact same results in 1 to 2 seconds. A few months later after I learned a bit more about SQL and optimized it further (just by adding an index IIRC) and now it was fast enough to appear instantaneous.
I'm still far from an SQL expert, and certainly wasn't 15 years ago, but you can get a lot of win by just spending as little as one or two days learning about SQL. It really surprises me how some people don't.
Then again, for a very long time I thought awk was basically useless to learn, until I did last year after which I kicked myself for not learning it sooner as I had spent a ridiculous amount of time cooking up inferior solutions for ~20 years, and spending just an hour or two learning awk would have been a great ROI *shrug*.
I guess the moral of the story is that you can never be quite sure if something is useful or useless until you actually learn it.
With the rise of ORMS, I'm coming across more and more devs in my work that have no idea how to write performant SQL, and don't ever check to see what gets generated and run "behind the scenes"
64 and still crafting in C and assembly. Occasionally doing hardware design/specification work. I studiously avoided the management path my forty year career. The constant technology change is what has held my interest. A career in telecom: Metallic access -> DS0/DS1 -> SONET -> 56K/DSL -> MPLS -> ROADM -> OFDMA/LTE -> WiFi/BT/Lora/Zigbee. Never look back. I cannot even imagine the page count of standards documents, requirements, and manufacturers user and programmers guides I have read in the last forty years.
Had to come back and add. I am doing a lot more embedded python utilities in the last three years, but it is all interfacing to C based firmware on raw silicon underneath.
spent 4 decades programming, and everything changes all the time
A half-aged kid here. This is the source of my anxiety, that all I’ve done and learned will age, slip through fingers and become forgotten. I wish our craft could stabilize on something, but it just doesn’t.
It does if you specialize in something that barely moves (AS/400, COBOL, others), but the experience of that career is almost the exact opposite of why many people get in to programming (lots of paperwork, consensus-based decisions, lots of waiting around trying to look busy, little new growth or exploration).
However, there is some light at the end of the “everything changes” tunnel: as you learn different frameworks and languages you’re gaining new perspectives on the deeper concepts, and for the most part those deeper concepts don’t change. In OOP the “gang of four” is practically as relevant now as it was then, for example.
Change is the only constant, I guess. This has always been part of anything computer-related. My dad started his career with punch cards, ended doing Java. You keep learning. But you've got to do that to some extent in every career.
If anything, things are stabilizing now more than ever before. Java and Javascript are almost 30 years old, and still as relevant as ever. Computers have been "fast enough" for most purposes and aren't obsolete the moment you've bought them, like they were in the early 1990s. The x86 architecture is surprisingly still with us. And despite all the new languages and frameworks, there's still tons of stuff being done in all of the old ones. They don't get obsolete as fast as they used to.
You can never do everything. Pick what you love, and focus on that.
> If your programming no longer excites you, learn something new in programming, or even learn something that isn't programming and do that.
This is the key right here. If what you used to do is no longer exciting you, it is time to try something else. This often means getting out of your comfort zone, and there is no guarantee that the new thing you try will excite you. But if that happens, at least you tried. Every discovery of something that doesn't interest you is a step closer to something that does.
[
A quote from a novel has always been an inspiration since I read it in high school - "An artist must leave a body of work" from The Agony And The Ecstasy, about Michelangelo. If your programming no longer excites you, learn something new in programming, or even learn something that isn't programming and do that. It's not easy, and might cost you money, but wasting your life doing something you no longer care about is not worth it.
-What about economics, a management role or something else?
my advice: Have the habbit to improve your habbits (including your thinking)
the medicine = reading btw
A quote from a novel has always been an inspiration since I read it in high school - "An artist must leave a body of work" from The Agony And The Ecstasy, about Michelangelo. If your programming no longer excites you, learn something new in programming, or even learn something that isn't programming and do that. It's not easy, and might cost you money, but wasting your life doing something you no longer care about is not worth it.
Of course some people can deal with a terrible job, and just spend the non-working time doing what they love, and that's OK if you can deal with it. I could never do that; I didn't turn to art until the last few years.